Budget-based flat rate play contract parameters

ABSTRACT

According to some embodiments, systems, methods, and/or articles of manufacture are associated with operating a gaming device having a flat rate play session or contract costing a flat rate price. The flat rate play session or contract spans multiple plays on the gaming device over a pre-established duration. In some embodiments, an expected cost of the flat rate play session or contract may be determined. In some embodiments, a flat rate play session or contract and/or one or more parameters thereof may be determined based upon a price (or other parameter) that a player is wiling to pay for flat rate play at a gaming device.

This application claims priority and benefit under 35 U.S.C. §119(e) toU.S. Provisional Patent Application Ser. No. 60/627,670, filed on Nov.12, 2004 and entitled “GAMING DEVICE OFFERING A FLAT RATE PLAY SESSIONAND METHODS THEREOF”, the entirety of which is incorporated by referenceherein.

SUMMARY

In accordance with some embodiments, there is provided a method,apparatus, and/or article of manufacture for providing a gaming sessionusing a gaming device. In one embodiment, a method comprisesdetermining, based at least upon a duration of a flat rate playcontract, a cost of the flat rate play contract. The duration maycomprise, for example, a specified amount of time and/or a specifiednumber of game plays (e.g., handle pulls of a slot machine and/or handsdealt via a video poker machine). The method may further comprise,according to some embodiments, determining a rule defining a desiredprofit rate for the flat rate play contract, calculating a desiredprofit margin for the flat rate play contract by multiplying the desiredprofit rate for the flat rate play contract by the duration of the flatrate play contract, and calculating a price for the flat rate playcontract by adding the desired profit margin for the flat rate playcontract to the cost of the flat rate play contract. In such a manner,for example, flat rate play contracts and/or sessions may be priced tosubstantially comply with and/or realize one or more desired profitrates. According to some embodiments, an apparatus comprises means foreffectuating the method such as a memory, a processor, and/or an inputdevice (e.g., to receive an indication of the desired profit rate rulefrom an operator).

According to some embodiments, a method, apparatus, and/or article ofmanufacture may provide for determining, based at least upon durationsof a plurality of flat rate play contracts, a cost of each of theplurality of flat rate play contracts, determining a rule defining adesired profit rate for a gaming device offering the plurality of flatrate play contracts, calculating a desired profit margin for each of theplurality of flat rate play contracts by multiplying the desired profitrate for the gaming device by the durations of each of the plurality offlat rate play contracts, and calculating a price for each of theplurality of flat rate play contracts by adding the desired profitmargin for each of the plurality of flat rate play contracts to the costof each of the plurality of flat rate play contracts. In such a manner,for example, flat rate play contracts and/or sessions may be priced tosubstantially comply with and/or realize one or more desired profitrates associated with one or more gaming devices.

BRIEF DESCRIPTION OF THE DRAWINGS

An understanding of embodiments described herein and many of theattendant advantages thereof may be readily obtained by reference to thefollowing detailed description when considered with the accompanyingdrawings, wherein:

FIG. 1 is an overall schematic view of a system according to someembodiments;

FIG. 2A is a schematic view of a gaming device according to someembodiments;

FIG. 2B is a plan view of a gaming device according to some embodiments;

FIG. 3 is a schematic view of a network server according to someembodiments;

FIG. 4 is a schematic view of a casino player database according to someembodiments;

FIG. 5 is a schematic view of a flat rate database according to someembodiments;

FIG. 6 is a schematic view of a payout table according to someembodiments;

FIG. 7 is a schematic view of a calculation table according to someembodiments;

FIG. 8A and FIG. 8B are flow diagrams of a method according to someembodiments;

FIG. 9 is a flow diagram of a method according to some embodiments;

FIG. 10 is a flow diagram of a method for terminating play according tosome embodiments;

FIG. 11A and FIG. 11B are flow diagrams of a method for resuming playaccording to some embodiments;

FIG. 12A and FIG. 12B are flow diagrams of a method according to someembodiments;

FIG. 13 is a flow diagram of a method for receiving a payout accordingto some embodiments;

FIG. 14 is a schematic view of a flat rate price package databaseaccording to some embodiments; and

FIG. 15 is a flow diagram of a method according to some embodiments;

FIG. 16 is a flow diagram of a method according to some embodiments;

FIG. 17 is a schematic view of a system according some embodiments;

FIG. 18 is a schematic view of a casino server according someembodiments;

FIG. 19 is a schematic view of an insurer device according someembodiments;

FIG. 20 is schematic view of a gaming device according some embodiments;

FIG. 21 is a schematic view of a player device according someembodiments;

FIG. 22 is a table illustrating an embodiment of a player databaseaccording some embodiments;

FIG. 23 is a table illustrating an embodiment of a gaming devicedatabase according some embodiments;

FIG. 24 is a table illustrating an embodiment of a contract databaseaccording some embodiments; and

FIG. 25 is a flowchart of a method according some embodiments.

DETAILED DESCRIPTION

I. Introduction

Certain embodiments will now be described in detail with reference tothe drawings. Although the embodiments discussed herein are primarilydirected to reel slot machines, it should be understood that suchembodiments are equally applicable to other gaming devices, such asvideo poker machines, video blackjack machines, video roulette, videokeno and the like.

Some embodiments are directed generally to a method and apparatus foroperating a gaming device having a flat rate play session. As usedherein, flat rate play session is generally defined as a period of playwherein the player need not make funds available for any individual playduring the play session. The flat rate play session may span multipleplays of the gaming device. These multiple plays are generallyaggregated into intervals or segments of play. It is to be understoodthat the term interval (and/or duration) as used herein could be time,handle pulls, and any other segment in which gaming device play could bedivided. For example, two hours, one hundred (100) spins, fifty (50)winning spins, etc. In some embodiments, a player may enterplayer-identifying information and/or player selected price parametersat a gaming device. The price parameters define the flat rate playsession, describing the duration of play, machine denomination, jackpotsactive, etc. The gaming device stores the player selected priceparameters and proceeds to retrieve and/or calculate the flat rate priceof playing the gaming device for the flat rate play session. The playerselected price parameters, in combination with operator priceparameters, determine the flat rate price. Should the player decide topay the flat rate price, the player simply deposits that amount into thegaming device and/or makes a credit account available for the gamingdevice to debit. For example, it might cost twenty-five dollars ($25) toplay for half an hour.

Once the player initiates play, the gaming device tracks the flat rateplay session and stops the play when the session is completed, usuallywhen a time limit has expired. During the play session, the player isnot required to deposit any coins. Payouts are made either directly tothe player in the form of coins or indirectly in the form of credits tothe credit balance stored in the machine. It should be understood thatthe player balance could be stored in a number of mediums, such as smartcards, credit card accounts, debit cards, and/or hotel credit accounts.

In some embodiments, the expected cost of a flat rate play sessionand/or a contract associated therewith may be determined by a gamingdevice, server, and/or other processing device. Various methods may beemployed to determine flat rate play costs including, but not limitedto, (i) simulation, (ii) mathematical simulation, (iii) mathematicalmodeling, and/or (iv) reactive pricing (e.g., based on historicalcosts). According to some embodiments, a profit margin may be added tothe cost to determine a price (e.g., a retail price) for a flat rateplay session and/or contract. Further, such prices may be set, updated,modified, and/or otherwise managed by an operator and/or by a gamingdevice or gaming server. In some embodiments, flat rate play prices maybe modified and/or set based upon one or more pre-defined rules. Agaming device may, for example, utilize pre-defined rules toautomatically and/or dynamically modify and/or set flat rate playprices.

II. System Architecture

Referring initially to FIG. 1, an overall schematic view of a system 100according to some embodiments is shown. In general, the system 100 maycomprise multiple slot machines 102 and/or a slot network server 106. Insome embodiments, each slot machine 102, which may be uniquelyidentified by a machine identification (ID) number, communicates withthe slot network server 106 via a slot network 104. The slot network 104is preferably a conventional local area network controlled by the slotnetwork server 106. It is to be understood, however, that otherarrangements in which the slot machines 102 communicate with the server106 are within the scope of some embodiments.

As will be described in greater detail elsewhere herein, in oneembodiment, the slot machine 102 communicates player-identifyinginformation to the slot network server 106. The slot network server 106,in turn, verifies the player-identifying information. The slot machine102 also calculates a flat rate price based on both player selected andcasino determined price parameters and displays the flat rate price tothe player. The player may then accept the flat rate price and initiateplay. In some embodiments, methods may be practiced without the slotnetwork server 106, in an arrangement in which the slot machine 102calculates the flat rate price.

III. Device Architectures

Turning to FIG. 2A, a schematic view of a gaming device 202 according tosome embodiments is shown. In some embodiments, the gaming device 202may be similar in configuration and/or functionality to one of the slotmachines 102 of FIG. 1. While the gaming device 202 may comprise anytype of gaming device (such as a video poker machine), for ease ofexplanation it will be assumed for exemplary purposes that the gamingdevice 202 comprises the slot machine 102 from FIG. 1. For example, aslot machine 202 may contain a Central Processing Unit (CPU) 210, aclock 212, and/or an operating system 214 (typically stored in memory assoftware). The CPU 210 executes instructions of a program stored in ReadOnly Memory (ROM) 216 for playing the slot machine 202. The RandomAccess Memory (RAM) 218 temporarily stores information passed to it bythe CPU 210 during play. Also in communication with the CPU 210 is aRandom Number Generator (RNG) 220.

With respect to gaming operations, the slot machine 202 operates in aconventional manner. The player starts the slot machine 202 by insertinga coin into a coin acceptor 248, or using electronic credit, andpressing and/or interfacing with a starting controller 222. Undercontrol of a program—stored for example in a data storage device 224and/or ROM 216—the CPU 210 initiates the RNG 220 and/or causes the RNG220 to generate a random number. The CPU 210 looks up the generatedrandom number in a stored probability table 226, which contains a listthat matches random numbers to corresponding outcomes, and identifiesthe appropriate outcome. Based on the identified outcome, the CPU 210locates the appropriate payout in a stored payout table 228. The CPU 210also directs a reel controller 230 to spin reels 232, 234, 236 and tostop them at a point when they display a combination of symbolscorresponding to the appropriate payout. When the player wins, themachine stores the credits in RAM 218 and displays the current balancein video display area 238. In an alternate embodiment, the slot machine202 dispenses the coins to a payout tray (not shown), and in anotherembodiment, a server (also not shown) such as the slot network server106 from FIG. 1 stores the player credits.

In some embodiments, a hopper controller 240 may be connected to ahopper 242 for dispensing coins. When the player requests to cash out bypushing a cash-out button (not shown) on the slot machine 202, the CPU210 checks the RAM 218 to see if the player has any credit and, if so,signals the hopper controller 240 to release an appropriate number ofcoins into a payout tray (also not shown). A coin acceptor 248 may alsobe coupled to the CPU 210. Further, the CPU 210 may register any coinreceived by the coin acceptor 248.

In some embodiments, the slot machine 202 may not include the reelcontroller 230 and/or reels 232, 234, 236. Instead, a video display area238 may graphically display representations of objects contained in theselected game, such as graphical reels or playing cards. Theserepresentations are preferably animated to display playing of theselected game.

Also in communication with the CPU 210 is a player tracking device 260.The tracking device 260 may comprise, for example, a card reader 266 forreading player-identifying information stored on a player tracking card(not shown). As used herein, the term player-identifying informationdenotes any information or compilation of information that identifies(e.g., uniquely) a player. In some embodiments, the identifyinginformation is a player identification (PID) number. Although not solimited, the player tracking card generally stores the PID on a magneticstrip located thereon. Such a magnetic strip and device to read theinformation stored on the magnetic strip are well known.

The player tracking device 260 may also and/or alternatively include adisplay 262 and/or a player interface 264. The player interface 264 mayinclude, for example, a keypad and/or a touch-screen display. Inoperation, as discussed elsewhere herein, the slot machine 202 maydisplay a message prompting the player to enter player selected priceparameters. In some embodiments, a player may enter the player selectedprice parameters via the player interface 264. Because the playerinterface 264 is generally part of the player tracking device 260, itis, therefore, generally in communication with the CPU 210.Alternatively, input of selected price parameters may be accomplishedthrough video display area 238 if it is configured with touch-screencapabilities.

The slot machine 202 may also or alternatively include a series of betbuttons 272, 274, 276. The bet buttons 272, 274, 276 may generallyinclude a “Bet 1 coin” button 272, a “Bet 2 coins” button 274, and/or a“Bet 3 coins” button 276. The bet buttons 272, 274, 276 may be coupledto the CPU 210. Therefore, pressing one of the bet buttons 272, 274, 276may cause a signal to be transmitted to the CPU 210, the signalindicating how much a player desires to wager on a given play.

In some embodiments, the data storage device 224 may store one or moredata structures 226-229, 246. The data structures 226-229, 246 stored inthe data storage device 224 may generally include a probability table226, a calculation table 227, a payout table 228, a flat rate pricepackage database 229, and/or a flat rate database 246. As discussed ingreater detail elsewhere herein, the flat rate database 246 and thecalculation table 227 may store information related to the flat rateplay session and calculation of the flat rate price, respectively. Theflat rate price package database 229 may store information describingdifferent pre-established flat rate packages as defined by the casinoand/or an operator associated therewith.

In some embodiments, the CPU 210 may also be connected to a slot networkinterface 250. The slot network interface 250 provides a communicationpath from the slot machine 202 to a server (not shown), such as the slotnetwork server 106 of FIG. 1, through a network (not explicitly shown),such as the slot network 104 of FIG. 1. Thus, as discussed in greaterdetail elsewhere herein, information is communicated among the playertracking card, player tracking device 260, slot machine 202, and slotnetwork server 106.

Referring now to FIG. 2B, the plan view of a gaming device 202 accordingto some embodiments is shown. In some embodiments, the gaming device 202may be the same gaming device illustrated in FIG. 2A. The gaming device202 may, for example, comprise the slot machine 102. For example, FIG.2B may generally depict a slot machine 202 comprising components 222,228, 232, 234, 236, 238, 248, 264, 272, 274, 276 that may be similar inconfiguration and/or functionality to the similarly-named and/ornumbered components described in conjunction with FIG. 2B. In someembodiments, the slot machine 202 may display (as shown in FIG. 2B)player-selected price parameter options on the video display area 238.Included in the displayed parameters is an amount wagered per play 712,an interval 714, an interval duration 722, and/or active paycombinations 720. As will be described further elsewhere herein, afterthe player has selected the desired price parameters, the slot machine202 may generally display a flat rate price 724. Once the player hasaccepted the flat rate price 724 and made the appropriate fundsavailable, flat rate play may commence.

Turning to FIG. 3, a schematic view of a network server 306 according tosome embodiments is shown. The slot network server 306 may, for example,be similar to the slot network server 106 described in conjunction withFIG. 1. According to some embodiments, the slot network server 306 maycomprise a CPU 310. The CPU 310, may have a dock 312 associatedtherewith, and/or may execute instructions of a program stored in ROM320. During execution of the program instructions, the CPU 310 maytemporarily store information in the RAM 330. Additionally, the CPU 310may be coupled to a data storage device 340, having a flat rate database346, a transaction processor 342, and/or a casino player database 344.In general, the transaction processor 342 manages the contents of thedata storage device 340. In some embodiments, the casino player database344 stores information specific to each player, includingplayer-identifying information. In some embodiments, the components 310,312, 320, 330, 340, 342, 344, 346 of the slot network server 306 may besimilar in configuration and/or functionality to the similarly namedand/or numbered components described in conjunction with any of FIG. 1,FIG. 2A, and/or FIG. 2B.

In some embodiments, in order to communicate with one or more slotmachines (not shown; such as the slot machines 102, 202 describedherein), the slot network server 306 also includes a communication port350. The communication port 350 is coupled to the CPU 310 and a slotmachine interface 360. Thus, the CPU 310 can control the communicationport 350 to receive information from the data storage device 340 and RAM330 and transmit the information to the slot machines 102, and viceversa.

It is to be understood that because the slot machines are generally incommunication with the slot network server 306, information stored in aslot machine may be stored in the server 306, and vice versa. Thus, forexample, in some embodiments, the slot network server 306 rather thanthe slot machine may include various data structures (some of which arenot shown in FIG. 3) such as the payout table 228 of FIG. 2A, the flatrate database 346 (that may be similar to the flat rate database 246 ofFIG. 2A), and/or the calculation table 227 of FIG. 2A.

IV. Data Structures

A. Casino Player Data Structure

Referring now to FIG. 4, a schematic view of a casino player database444 according to some embodiments is shown. In some embodiments, thecasino player database 444 may be similar in configuration and/orfunctionality to the casino player database 344 of FIG. 3. The casinoplayer database 444 may include, for example, multiple records havingmultiple fields of information. Specifically, the casino player database444 generally comprises multiple records, each record being associatedwith a particular player, as identified by a player ID number. Thefields within each record may include: a player ID field 410, a socialsecurity number field 412, a name field 414, an address field 416, atelephone number field 418, a credit card number field 420, a creditbalance field 422, and/or complimentary information, such as a totalaccumulated complimentary points field 424, a hotel guest field 426(e.g., indicating whether the player is a hotel guest), a player statusrating field 428, and/or a value of interval remaining field 430. Havinginformation related to one field, such as the player ID field 410,allows a server or other device (such as the slot network server 106,306 of FIG. 1 and/or FIG. 3) to retrieve all information stored incorresponding fields 410, 412, 414, 416, 418, 420, 422, 424, 426, 428,430 of that player record.

It is to be understood that not all of these fields 410, 412, 414, 416,418, 420, 422, 424, 426, 428, 430 are necessary for operation of someembodiments. For example, the name field 414, the social security numberfield 412, the address field 416, the telephone number field 418, thecredit card number field 420, and/or the hotel guest field 426 aremerely representative of additional information that may be stored andused for other purposes. In one embodiment, the credit card number field420 and the hotel guest field 426 are used for billing purposes and thesocial security number field 412 is used to generate tax forms when aplayer wins a jackpot over a given amount.

The total accumulated complimentary points field 424 is furtherillustrative of additional information a casino may store in a player'srecord. In some embodiments, a player's complimentary points aredisplayed to the player when a player tracking card is inserted into aslot machine (such as the slot machine 102, 202 of FIG. 1, FIG. 2A,and/or FIG. 2B). In an alternate embodiment, such points may be used inaddition, or as an alternative to the credit balance field 422, that mayfor example be stored in the RAM 218 of the slot machine 202 describedin conjunction with any of FIG. 2A and/or FIG. 2B.

The player status rating field 428 generally contains informationrepresentative of the particular player's relative importance to thecasino, as based upon the frequency and/or duration of the player'svisits, the amount of money wagered, and/or the like.

The value of interval remaining field 430 stores the value of intervalremaining in a flat rate play session and/or contract when a playerterminates the play session prior to its expiration. This field will bedescribed in greater detail elsewhere herein.

B. Flat Rate Data Structure

Reference is now made to FIG. 5, where a schematic view of a flat ratedatabase 546 according to some embodiments is shown. In someembodiments, the flat rate database 546 may be similar in configurationand/or functionality to the flat rate database 246 of the slot machine202 in FIG. 2A. The flat rate database 546 may comprise, for example,multiple records, each record pertaining to a flat rate play session ofa particular player (e.g., as identified by that player's ID number).Consequently, one field in flat rate database 546 is the player IDnumber field 510. Other fields may include: a player selected priceparameters field 512, a flat rate price field 514, an interval remainingfield 516, a time audit data field 518, and/or a machine ID number field520. The machine ID number field 520 contains the machine ID number thatuniquely identifies a gaming device utilized by the player (such as theslot machine 102, 202 of FIG. 1, FIG. 2A, and/or FIG. 2B). It is to beunderstood that since both the casino player database 444 of FIG. 4 andthe flat rate database 546 may generally include the respective playerID fields 410, 510, a system (such as the system 100 of FIG. 1) cancorrelate any player information stored in the casino player database444, with any player information stored in the flat rate database 546(e.g., the database tables and/or records thereof may be linked).

C. Payout Data Structure

Turning now to FIG. 6, a schematic view of a payout table 628 accordingto some embodiments is shown. In some embodiments, the payout table 628may be similar in configuration and/or functionality to the payoutdatabase 228 described in conjunction with FIG. 2A. As shown in FIG. 6,the payout table 628 may comprise five fields of related information(although fewer or more fields may be includes, as is or becomespracticable). The first field, a pay combination field 610, identifiesthe set of possible pay combinations for a given gaming device (such asthe slot machine 102, 202 of FIG. 1, FIG. 2A, and/or FIG. 2B). Suchpossible pay combinations include winning pay combinations, or those inwhich a payout results, and non-winning pay combinations, in which theplayer receives no payout and consequently loses the amount wagered.Winning pay combinations include, for example, “DOUBLE JACKPOT DOUBLEJACKPOT DOUBLE JACKPOT” and “BAR BAR BAR.” The pay combinations field610 may also include a “NON WINNING OUTCOMES” record, an entryrepresenting the outcomes which result in no payout to the player, suchas “PLUM BELL ORANGE.”

The payout table 628 may also include three (3) payout fields 620, 630,640. Such payout fields 620, 630, 640 contain the payout information foreach of the possible pay combinations identified in the pay combinationsfield 610. Each of the payout fields 620, 630, 640 may be identified bythe number of coins wagered on a particular play (e.g., as selected viathe bet buttons 272, 274, 276 of FIG. 2A and/or FIG. 2B). In someembodiments, the payout table 628 contains a “1 coin” payout field 620,which is accessed when one (1) coin is wagered, a “2 coins” payout field630, which is accessed when two (2) coins are wagered, and a “3 coins”payout field 640, which is accessed when three (3) coins are wagered. Inother words, each payout field 620, 630, 640 may correspond to arespective bet button 272, 274, 276 of FIG. 2A and/or FIG. 2B. Thepayout information provides the number of coins won upon the occurrenceof a particular pay combination. Thus, “CHERRY CHERRY CHERRY” pays outten (10) coins when one (1) coin is wagered.

Finally, the payout table 628 may include a pay combination status field650. The pay combination status field 650 generally includes anindication for each winning pay combination, identified in the paycombination field 610, of whether the player is eligible to win thepayout for each outcome. As will be described elsewhere herein, thedetermination of whether a player is eligible to win a payout for agiven outcome may be made by the player as part of the player-selectedprice parameters.

D. Calculation Data Structure

Referring now to FIG. 7, a schematic view of a calculation table 727according to some embodiments is shown. In some embodiments, thecalculation table 727 may be similar in configuration and/orfunctionality to the calculation table 227 described in conjunction withFIG. 2A. The calculation table 727 may be used, for example, by thesystem 100 of FIG. 1 in determining a flat rate price to be charged tothe player, which may be stored in a flat rate price field 724 (and/orin the flat rate price field 514 of the flat rate database 546 of FIG.5). Specifically, the calculation table 727 contains multiple priceparameters that are correlated to the flat rate price field 724. Morespecifically, these price parameters may include player selected priceparameters and/or operator selected price parameters. In general, playerselected price parameters include any game related variable that definesthe flat rate play session and/or contract. Furthermore, operatorselected price parameters are parameters that the operator of a gamingdevice (such as the slot machines 102, 202 of FIG. 1, FIG. 2A, and/orFIG. 2B) selects as affecting the values stored in the flat rate pricefield 724. Thus, in some embodiments, the player selected priceparameters in the calculation table 727 may be represented by a machinetype field 710, an amount wagered per play field 712, an active paycombinations field 720, and/or a duration of the flat rate play sessionfield 722. The operator selected price parameters in the calculationtable 727 include player a status rating field 714, a time of day field716, a day of the week field 718, and/or a machine usage field 719. Insome embodiments the values stored in the flat rate price field 724 arepredetermined based upon the aforementioned price parameters and storedin the calculation table 727, as will be described in more detail withrespect to FIG. 14 and FIG. 15 elsewhere herein. In an alternateembodiment the values of the flat rate price field 724 are calculatedbased upon these parameters as needed according to a price algorithmstored in memory. For example, the price algorithm may operate asfollows.

1. Exemplary Pricing Algorithm

The are any number of algorithms that could be used to calculate a flatrate price, and they can be generally described as calculating anexpected value to the customer and then adding in a margin (e.g., aprofit margin) for the casino or adjusting the price to reflect the timeof day, value of the customer, etc.

The first step may generally be to determine a “base” flat rate price.This may be calculated in accordance with “Formula (1)”, as follows:Base Price=[(amount wagered)×(interval)]×[(expected coins awarded forall active pay combinations over a cycle/expected coin-in over acycle)].  (1)

For example, the following base price calculation represents a playerselecting three dollar ($3) coins per handle pull, an interval of fivehundred (500) handle pulls, and the top three (3) pay combinationsactive. For this example we will assume that a complete cycle of theslot machine is ten thousand, six hundred and forty-eight (10,648)unique outcomes and that the top three (3) pay combinations would beexpected to pay two thousand, one hundred and sixty (2,160) coins overthat cycle. Note also that the expected coins awarded for all active paycombinations over a cycle and the expected coin-in over the cycle shouldboth reflect the same number of coins wagered. Essentially, this ratioreflects the expected monetary return to the payer on a per coin wageredbasis. When multiplied by the amount wagered and the number of handlepulls, the number reflects the amount of money that the player would beexpected to receive from the machine over the interval specified. Itshould be noted that this amount of money is not necessarily the numberof coins entered by the player but rather is the theoretical number ofcoins of play allowed by the flat rate session. Continuing with thecalculation (utilizing “Formula (1)”) in accordance with the numbersprovided in the example, we have: Base Price = [($3) × (500)] ×[(2,160/10,648)] = $1,500 × .202855 = $304.28

Note that if the player were to pay this base price he would beessentially getting a fair bet for his money. He would pay three hundredand four dollars and twenty-eight cents ($304.28) for the session andexpect (over the long run) to get three hundred and four dollars andtwenty-eight cents ($304.28) back in prize money from the top three (3)active pay combinations. Of course in the short run his results couldrange from receiving no payouts over the interval to receiving thousandsof dollars. Because this base price is a fair bet for the player thecasino may want to add in a margin for the house, perhaps by multiplyingthe base price by a predetermined margin factor such as fifty percent(50%). In this example the profit-adjusted price would thus simply be:profit adjusted price = $304.28 × 150% = $456.42

Of course the casino might want to offer flat rate sessions to playerswithout a casino markup under some circumstances, such as part of apromotional package or to reward a particularly loyal customer. In factthe casino might even decrease the base price in some circumstances(e.g., subsidize flat rate play sessions and/or portions thereof).

In some embodiments, the base price (and/or profit adjusted price) couldbe further modified by various other operator price parameters such asthe following:

a) Time of Day (TD)

Times of the day in which the casino traffic tends to be heavy shouldresult in the player paying a premium for the flat rate play session,while quiet times in the casino should offer the player a discount overnormal rates. For example, the profit margin factor utilized to adjustthe base price may be determined based on the following time periods:Midnight to 4 am 70% 4 am to 8 am 80% 8 am to 12 pm 90% 12 pm to 4 pm100%  4 pm to 8 pm 120%  8 pm to Midnight 140% 

b) Day of Week (DW)

With the heaviest volume of visitors generally falling on Fridays andSaturdays, these days may necessitate higher flat rate session costs.For example, the profit margin factor utilized to adjust the base pricemay be determined based on the following periods: Monday to Thursday 80% Friday 120% Saturday 140% Sunday 100%

c) Player Status Rating (PSR)

For top customers such as high rollers, the cost of a flat rate sessionmay be reduced as a customer retention tool. For example, the profitmargin factor utilized to adjust the base price may be determined basedon the following classifications: 1 (High Roller) 80% 2 (Good customer)90% 3 (Average) 100%  4 (Low) 120% 

d) Slot Machine Usage (SMU)

When the majority of slot machines in the casino are being used, apremium may be applied to the cost of the flat rate play session inorder to more evenly distribute play. For example, the profit marginfactor utilized to adjust the base price may be determined based on thefollowing usage classifications: Heavy 120% Moderate 100% Light  80%

In some embodiments, the flat rate price may accordingly be calculatedto incorporate such parameters pursuant to “Formula (2)”, as follows:Flat rate price=Base Price×TD×DW×PSR×SMU  (2)

As an example: the player is in the casino at two in the morning (2 AM)on a Wednesday, there is low slot machine usage, and the player has anaverage rating. Thus, “Formula (2)” may be utilized to reflect theseconditions, as follows: (Base Price = $304.28; from above) Final flatrate price = (Base Price) × TD × DW × PSR × SMU = $304.28 × 70% × 80% ×100% × 80% = $304.28 × 44.8% = $136.32

The casino may round up this price to one hundred and thirty-sevendollars ($137) to avoid the need for small change. In the abovecalculations, the casino might also incorporate floors which prevent thebase price from going below a level that would be profitable for thehouse, regardless of the number of positive criterion that were appliedto the base price.

Those of ordinary skill in the art will appreciate that modificationscould be made to the formulas (e.g., “Formula (1)” and/or “Formula (2)”)to reflect different kinds of flat rate sessions and/or contracts. For asession with an interval of one (1) hour (instead of a fixed number ofhandle pulls) the formula might reflect an expected number of handlepulls per hour for that particular game, perhaps even adjusted toreflect the type of player purchasing the flat rate session. Forexample, an experienced video poker player might be expected to reachseven hundred (700) hands per hour while a beginner might only beexpected to reach three hundred (300) hands per hour.

As will also be understood by those skilled in the art, the ultimategoal of many slot machine players is to hit a jackpot payout. Theenjoyment of the play, as well as the ability to maximize the chance ofhitting a large jackpot, is increased by more play. Play can beincreased both by playing longer and by playing faster. As will beappreciated from a consideration of the processes described herein, someembodiments permit, facilitate, and/or encourage both increasedduration, by providing for play at discounted prices, and speed of play,by providing for minimal time delays between plays.

E. Flat Rate Package Data Structure

Turning to FIG. 14, a schematic view of a flat rate price packagedatabase 1429 according to some embodiments is shown. In someembodiments, the flat rate price package database 1429 may be similar inconfiguration and/or functionality to the flat rate price packagedatabase 229 described in conjunction with FIG. 2A. The flat rate pricepackage database 1429 may be used, for example, by the system 100 ofFIG. 1 in providing a player with different price package options forflat rate play of the slot machine 102 of FIG. 1. Specifically, the flatrate price package database 1429 may contain multiple combinations, orpackages (e.g., identified by package numbers stored in a package IDfield 1410), of price parameters that correspond to pre-established flatrate prices. More specifically, these price parameters may berepresented by an interval field 1412, a duration of flat rate playfield 1414, an amount wagered per play field 1416, and/or a paycombination status field 1418. Each combination of price parameters maygenerally be represented by a corresponding flat rate play session pricestored in a flat rate play session price field 1420. As is describedwith reference to FIG. 15 herein, the flat rate price package database1429 may be accessed when the player wishes to initiate a flat rate playsession. Rather than let the player choose the price parameters,according to some embodiments, the slot machine 102, 202 may list thedifferent packages stored in the flat rate price package database 1429.The player may then choose a package and play may commence.

V. Processes

Having thus described the components of some embodiments, an exemplaryoperation of the system 100 of FIG. 1 will now be described in greaterdetail with reference to FIG. 8, FIG. 9, FIG. 10, and FIG. 11, withcontinued reference to FIG. 1, FIG. 2A, FIG. 2B, FIG. 3, FIG. 4, FIG. 5,FIG. 6, and FIG. 7. It is to be understood that the programs stored inROM 320 of the slot network server 306 of FIG. 3 and ROM 216 of the slotmachine 202 of FIG. 2A may provide any of the functionality describedherein.

Turning to FIG. 8A and FIG. 8B, flow diagrams of a method 800 accordingto some embodiments are shown. The method 800 may, for example,illustrate the general operation of the system 100 of FIG. 1. As shownin step 810, the slot machine player first inserts the player trackingcard into a card reader (e.g., such as the card reader 266 of FIG. 2A).The card reader then proceeds to read player-identifying informationfrom the tracking card. The player identifying information, namely theplayer ID number, is communicated from a slot machine (such as the slotmachine 102, 202 of FIG. 1, FIG. 2A, and/or FIG. 2B) to a slot networkserver (such as the slot network server 106, 306 of FIG. 1 and/or FIG.3), in step 812.

Upon receiving the player identifying information, the slot networkserver verifies the information in step 814. Such verification includesthe slot network server searching a casino player database (such as thecasino player database 344, 444 of FIG. 3 and/or FIG. 4) for a recordcontaining the received player ID number in the appropriate field (e.g.,the player ID field 410 of FIG. 4). Once the slot network serververifies the player identifying information, the slot network servertransmits a signal to the slot machine acknowledging such verificationin step 816. In alternate embodiments, other information, such as theplayer's name (e.g., stored in the name field 414 of FIG. 4), acomplimentary point total (e.g., stored in the complimentary pointsfield 424 of FIG. 4), and/or a player status rating (e.g., stored in theplayer rating field 428 of FIG. 4) are transmitted to the slot machinefor display.

In step 818, the player selects flat rate play via a player interface(such as the player interface 264 of FIG. 2A and/or FIG. 2B). The CPU(e.g., CPU 210 of FIG. 2A) of the slot machine, in step 820, thenreceives a signal from the player interface, indicating that the playerhas selected flat rate play. For example, there could be a buttonspecifically for triggering a flat rate play session. The CPU, inresponse, accesses memory to retrieve player selectable priceparameters. Player selectable price parameters are the choices availableto a player for entering the player selected price parameters. Theseplayer selectable price parameters are controlled by a program stored inmemory (such as the ROM 216 of FIG. 2A). Such player selectable priceparameters, in the present embodiment, include the amount wagered perplay (e.g., one, two, or three coins), the length of the flat rate playsession, and possible jackpot structures, such as having only the“DOUBLE JACKPOT” and “5 BAR” jackpots active (as illustrated in thepayout table 628 of FIG. 6). In an alternate embodiment, the playerselectable price parameters are stored as part of a calculation table(such as the calculation tables 227, 727 of FIG. 2A and/or FIG. 7).

Then, as shown in step 822, the slot machine displays the playerselectable price parameters to the player. For example, the parameterscould be listed on a video display area (e.g., the video display area238 of FIG. 2A and/or FIG. 2B) for the player. Once the parametersappear, the player simply selects the desired settings. Alternatively,the player may accept one or more default settings. Once the playerselectable price parameters are displayed on the display (and/orotherwise provided to the player), the player proceeds, in step 824, toenter player selected price parameters via the player interface. Theplayer selected price parameters may also include data that, althoughnot directly inputted by the player, is selected by the player andidentified by the slot machine. In the present embodiment, suchadditional player selected price parameters include the type of gamingdevice or machine, the time of day, and/or the day of the week.

It is to be understood that the casino operator of the slot machines maydefine the scope of the player selectable price parameters, andtherefore limit the player selected price parameters in any manner. Forexample, the length of flat rate play may be limited to periods above aminimum time or to periods that are multiples of thirty (30) minuteintervals. The jackpot structure may require that some jackpots remainactive.

Continuing to FIG. 8B, the method 800 may proceed to step 826, where theslot machine and/or CPU thereof receives the player selected priceparameters. Having received the player selected parameters, the CPU thenstores the player selected price parameters, the player identifyinginformation, and the slot machine's machine ID number in a record in aflat rate database (such as the flat rate database 246, 546 of FIG. 2Aand/or FIG. 5). Specifically, the player ID number may be stored in theplayer ID number field 510 of FIG. 5, the machine ID number may bestored in the machine ID number field 520 of FIG. 5, and/or the playerselected price parameters may be stored in the player selected priceparameters field 512 of FIG. 5. Although the player selected priceparameters are illustrated as being stored in a single field (e.g.,player selected price parameters field 512 of FIG. 5), it is to beunderstood that each player selected price parameter may be stored in aseparate field. It is also to be understood that in alternateembodiments the player selected price parameters need not be stored in adatabase, but could be stored in other memory such as the RAM 218 ofFIG. 2A.

In some embodiments, the slot machine and/or CPU thereof uses the playerselected price parameters to determine the flat rate prices.Specifically, in step 828, the CPU accesses the calculation table andsearches for the flat rate price (e.g., stored in the flat rate pricefield 724 of FIG. 7) corresponding to the received player selected priceparameters, which, in the present embodiment, include a machine type, anamount wagered per play, a time of day, a day of the week, activejackpots, and/or the length of the flat rate play session (e.g., storedin the respective fields 710, 712, 716, 718, 720, 722 of FIG. 7). TheCPU also may incorporate operator selected price parameters for the flatrate price, such as a player status rating and/or machine availability.As will be appreciated by one skilled in the art, the player statusrating is received from the casino player database at any time prior todetermination of the flat rate price. Thus, in some embodiments, theslot network server transmits the player status rating to the slotmachine along with the verification signal in step 816.

By including the player status rating in the calculation table, a casinomay reward frequent players who wager relatively large amounts of moneywith a lower flat rate price. Thus, the system 100 of FIG. 1 may rewardand/or encourage frequent play. By including active jackpots in thecalculation table, the system 100 of FIG. 1 allows a casino to discountthe flat rate price for those players who choose to enable relativelyfew winning outcomes in the payout table. Furthermore, by including theprice parameters relating to time of day and day of the week in thecalculation table, a casino may charge a lower flat rate price forsessions during weekday afternoons or between two in the morning (2 AM)and eight in the morning (8 AM), thereby encouraging play of the slotmachines when they are typically idle.

It is to be understood that the aforementioned price parameters in thecalculation table are merely representative of the type of variablesthat may be considered in determining a flat rate price. Thus, it iswithin the scope of some embodiments to include only some of the priceparameters, all of the parameters, or additional parameters in thecalculation table.

As mentioned herein, the flat rate price may be based partly upon theavailability of slot machines. In such an embodiment, the slot networkserver tracks whether each slot machine is being used by noting whetheroutcomes are currently being received from a given slot machine. Inanother embodiment, the slot network server tracks slot machineavailability by tabulating the number of slot machines for which flatrate play is currently enabled. In yet another embodiment, the slotnetwork server tracks slot machine availability by identifying how manyslot machines have a player tracking card inserted therein.

Another price parameter that may be used is predicted or forecasted slotmachine availability. Specifically, such a parameter accounts foranticipated availability of slot machines based upon events at thecasino. For example, the calculation table correlates a lower flat rateprice to a time of day corresponding to an event, such as a show thatmany casino players are likely to attend. On the other hand, thecalculation table correlates a higher flat rate price to a time of daycorresponding to the end of the event and/or to otherwise heavier casinotraffic. This allows a casino to effectively revenue manage their slotmachines without resorting to a change in hold percentage which requiresregulatory approval.

It is to be understood that accounting for slot machine availabilityneed not be accomplished in the calculation table. Rather, in analternate embodiment, a schedule of events is stored in memory (such asthe RAM 218 of FIG. 2A) that is accessed prior to transmitting the flatrate price to the player. If the event schedule indicates that an eventis ending during the requested flat rate play session, then the flatrate price will be incremented accordingly.

In another embodiment, the flat rate price is based only on operatorselected price parameters. A slot machine according to such anembodiment could, for example, provide discounted flat rate playsessions based on a player status rating, thereby offering one hundred(100) plays for the price of ninety (90) plays, and/or discounted timedsessions. To encourage repeat, high stakes play, higher player statusratings result in greater discounts.

Having determined the flat rate price, the slot machine, in step 830,displays the duration of the flat rate play session and the flat rateprice and requests approval from the player. Once the player accepts theterms of the flat rate play session, flat rate play commences.

If the player does not approve the flat rate price, then the playerindicates so via the player interface. As indicated by Path “A” in FIG.8A and FIG. 8B, the slot machine may repeat its operation from step 822.On the other hand, if the player approves the flat rate price, theplayer indicates such approval via the player interface in step 832.Following such approval, the slot machine prompts the player to enter anappropriate amount of money in step 834. In the present embodiment, theplayer deposits coins into the slot machine (e.g., via the coin acceptor248 of FIG. 2A and/or FIG. 2B). In one embodiment, the player deposits acasino token as payment for the flat rate play session. Such tokens maybe denominated in dollars, or represent a number of handle pulls. Acasino could thus sell a fifty (50) handle pull token, usable on aparticular denomination and/or type of machine. Such a token mayadditionally serve to activate the flat rate play session, eliminatingthe need for the player to select flat rate play via the playerinterface. Alternatively, a player's credit balance may be debited topay for the flat rate play session.

In some embodiments a casino token may be associated with a particularset of pay combinations that are to be active during a flat rate playsession activated via the token. In yet other embodiments a casino tokenmay be associated with (i) a specified duration of time, (ii) aspecified number of handle pulls or outcomes, (iii) a specified numberof winning handle pulls or outcomes, and/or (iv) a flat rate pricepackage as, for example, described with reference to the flat rate pricepackage database 1429 of FIG. 14. A gaming device may identify such atoken and enter the appropriate flat rate play session by, for example,the size and/or weight of the token or by reading or receivinginformation from the token (e.g., via a computer chip embedded in thetoken or special markings on the token). Such a casino token may be, forexample, purchased by a person and given to another person as a gift.The recipient may subsequently use the token by inserting it into anappropriate gaming device and essentially playing for “free” (since theperson that gave the gift had prepaid for the token) for a specifiedduration.

Once the CPU registers the receipt of money, the CPU reconfigures theslot machine for the flat rate play session in step 836. Specifically,the CPU generates a signal, or a flag in memory, indicating that thereis no need to accept the coins between plays (e.g., for the duration ofthe flat rate play session). CPU further sets an active flag (such asstored in the pay combination status field 650 of FIG. 6) in the payouttable according to the jackpot structure entered by the player.

The operation of a slot machine (and/or other gaming device) during aflat rate play session will now be described with reference to FIG. 9and with continuing reference to FIG. 1, FIG. 2A, FIG. 2B, FIG. 3, FIG.4, FIG. 5, FIG. 6, and FIG. 7. In FIG. 9, a flow diagram of a method 900according to some embodiments is shown. During a flat rate play session,for example, a slot machine operates generally as described above withreference to FIG. 2A and/or FIG. 2B. However, the slot machine may bereconfigured to operate according to the player selected priceparameters, if such parameters affect play, and to operate continuously,without requiring payment between each play. Specifically the method 900and/or the flat rate play session may begin when the player provides anindication (e.g., by presses the starting controller 222 of FIG. 2Aand/or FIG. 2B), in step 910. The CPU also initiates a countdown of thelength of the flat rate play session, such as may be stored in theplayer selected parameters field 512 of the flat rate database 546 ofFIG. 5. With the start of the session, the CPU stores the start time ofthe flat rate play session in the flat rate database. Specifically, thestart time may be stored in a time audit data field (such as the timeaudit data field 520 of FIG. 5), in step 912. In step 914, the CPUbegins to count down the duration of the flat rate play session. Next,in step 916, the slot machine generates an outcome and accesses thepayout table to determine the appropriate corresponding number of coinsto be paid out.

Furthermore, in step 918, after each outcome is generated, the slotmachine determines whether the countdown of the interval remaining hasreached zero. It is to be understood that the countdown may beimplemented in either software or hardware. Additionally, it isunderstood that the countdown process discussed herein may be replacedwith any suitable means for tracking the duration of the flat rate playsession. The interval remaining may also or alternatively represent thenumber of handle pulls remaining.

In the event that the countdown has not reached zero, the player pressesthe starting controller in step 920, thereby initiating another play ofthe slot machine. In the event that the countdown has reached zero, theCPU generates a signal indicating that the flat rate play session hasconcluded. The slot machine displays a message indicating this to theplayer and, in step 922, stores the end time of the session in the timeaudit data field of the flat rate database.

In an alternate embodiment, the player selected price parameters includethe “time between plays.” In this embodiment, the CPU of slot machinecontrols the time between generating outcomes of successive plays in theslot machine to equal the received “time between plays player selectedprice parameter. In another alternate embodiment, the slot machinetracks the number of plays during the flat rate play session. If thenumber of plays exceeds a predetermined limit, the slot machineautomatically terminates the flat rate play session, regardless of theduration of the flat rate play session.

Turning now to FIG. 10, a flow diagram of a method 1000 for terminatingplay according to some embodiments is shown. In some embodiments, themethod 1000 may illustrate the operation of the system 100 of FIG. 1when the player terminates the flat rate play session prior to theexpiration of the session. In step 1010, for example, the playerindicates a desire to terminate the flat rate play session via theplayer interface. Consequently, the slot machine CPU receives atermination signal and, in step 1012, displays a message to the player,asking the player to verify termination of the flat rate play session.If the player does not verify termination, then the session continues asdescribed with reference to the method 900 of FIG. 9. On the other hand,if the player verifies termination, shown as step 1014, the CPU proceedsto store the stop time in the time audit data field of the flat ratedatabase, in step 1016.

It is to be understood that having both the start time and the stop timeof the flat rate play sessions stored in the flat rate database allowsthe casino to perform an audit of the session. Specifically, should aplayer allege that the flat rate play session was shorter than thatwhich was paid for, the casino may access the flat rate database andretrieve the actual start and stop time from the time audit data field.In the present embodiment, this time includes an indication of the day,hour, and minute of the play session.

Next, in step 1018, the CPU determines the value of the intervalremaining in the flat rate play session and transmits the value to theslot network server. In order to determine the value of the intervalremaining, the CPU accesses the calculation table. The value of intervalremaining may, for example, equal the flat rate price corresponding tothe price parameters (e.g., the machine type, amount wagered per play,player status rating, time of day, etc.) used to determine the originalflat rate price charged to the player. When determining the value of theinterval remaining, however, the value in the duration of flat rate playsession field 722 of FIG. 7 is not the original length of the session,but rather is equal to the actual interval remaining in the flat rateplay session. Stated succinctly, the slot machine identifies the flatrate price corresponding to the actual interval remaining in the flatrate play session.

Once the value of interval remaining is determined, the slot machinetransmits the value to the slot network server. Upon receiving the valueof interval remaining, the slot network server may store the value inthe value of interval remaining field 430 of the casino player database444 of FIG. 4 of the player's record, as identified by the player's IDnumber. Storing the value is shown as step 1020. Finally, in step 1022,the player removes the player tracking card.

Referring now to FIG. 11A and FIG. 11B, flow diagrams of a method 1100for resuming play according to some embodiments are shown. In someembodiments, the method 1100 may be similar to the method 800 describedin conjunction with FIG. 8A and/or FIG. 8B. The initial operation of thesystem 100 of FIG. 1 may, for example, proceed normally as indicated bysteps 1110-1128.

However, once the CPU of slot machine determines a new flat rate pricebased on the relevant price parameters, the CPU determines whether theplayer must deposit additional funds.

Specifically, in step 1130, the CPU compares the new flat rate pricewith the value of interval remaining. The slot network server transmitsthe value of interval remaining, as stored in the casino player database444 of FIG. 4, to the slot machine in step 1116 so that the comparisonmay be performed. As indicated by step 1132, the comparison involvesdetermining whether the new flat rate price is higher than the value ofinterval remaining.

If the new price is not higher than the value of interval remaining,then, in step 1134, the slot machine allows the player to play the flatrate session at no cost. However, if the new flat rate price is higherthan the value of interval remaining, then, in step 1136, the CPUassigns the difference between the values as the new flat rate price.Thus, in step 1138, the CPU displays the new flat rate price on thevideo display area of the slot machine. Thereafter, operation of thesystem continues as described with reference to steps 832-836 of FIG.8B.

In an alternate embodiment, when a player terminates the flat ratesession early, the value of the interval remaining is added to theplayer's credit balance, as stored in the credit balance field 422 ofthe casino player database 444 of FIG. 4.

It is to be understood that some embodiments need not include both aslot machine and slot network server. For example, an embodimentemploying only a slot machine is within the scope of some embodiments.Such an embodiment will now be described with reference to FIG. 12A,FIG. 12B, and FIG. 13, and with continuing reference to FIG. 2, FIG. 5,and FIG. 7. Such an embodiment may generally utilize a gaming devicesuch as the slot machine 102, 202 of FIG. 1, FIG. 2A, and/or FIG. 2B.

Referring to FIG. 12A and FIG. 12B, for example, flow diagrams of amethod 1200 according to some embodiments are shown. In someembodiments, the method 1200 may begin when a player selects flat rateplay on the slot machine, in step 1210. Once the player selects flatrate play, the flat rate play signal is transmitted from the playerinterface to the CPU, in step 1212. The CPU then proceeds, in step 1214,to retrieve the player options for selectable price parameters. Then, instep 1216, the CPU transmits the player selectable price parameteroptions to the video display area for viewing.

Once the player selectable price parameter options have been displayedto the player, the player inputs the player selected price parametersthrough the player interface. Then, in step 1220, the CPU receives theplayer selected price parameters from the player interface.

Once the CPU receives the player selected price parameters, the CPUreconfigures the slot machine. Specifically, the CPU generates a signal,or a flag in memory, indicating that there is no need to accept thecoins between plays. The CPU further sets the pay combination statusfield in the payout table according to the jackpot structure entered bythe player. In an alternate embodiment in which the player selectableprice parameters include the time between the handle pulls, the CPU setsan internal timer.

Furthermore, once the slot machine CPU receives the player selectedprice parameters, it proceeds to access the calculation table. Byaccessing the calculation table, the CPU retrieves the flat rate pricefor the flat rate play session. Retrieving the flat rate price is shownas step 1224. Once the CPU retrieves the flat rate price, it proceeds totransmit the price, the length of the flat rate play session, andpayment instructions to the video display area for player viewing, instep 1226.

In step 1228, the player reads the data and instructions on the videodisplay area and inserts money into the coin acceptor or a bill acceptorin order to initiate play of the slot machine. In an alternateembodiment, the player enters a stored value card such as a “smart card”into the card reader. Such a smart card has the players credit balancestored thereon. Payment using a smart card further entails the CPUdebiting the players balance on the smart card by the amount of the flatrate price. Further, the player may enter a credit card into the cardreader.

In step 1230, the CPU generates a confirmed payment message indicatingthat the player has deposited sufficient funds to cover the flat rateprice. Consequently, the CPU, in step 1232, sends the current time toboth the video display area and the time audit field of flat ratedatabase. Next, in step 1234, the CPU initiates the countdown of theinterval remaining in the flat rate play session. The length of the flatrate play session received from the player may be initially stored inthe interval remaining field 516 of FIG. 5. The slot machine decrements,or counts down, this value as the flat rate play session begins.

As shown in step 1236, the flat rate play session continues inaccordance with the player selected price parameters, if such parametersaffect play, in step 1236. During such play, the CPU stores and updatesthe player's accumulated credits in memory (such as the RAM 218 of FIG.2A). In an alternate embodiment, the slot machine pays out jackpots asthey occur. Finally, in step 1238, the CPU terminates the flat rate playsession when the countdown ends.

In an alternate embodiment, the interval of the flat rate play sessionis not a time period, but rather is a maximum number of plays. In suchan embodiment, the slot machine stores the number of plays in the flatrate database, as described with respect to FIG. 9, and, in step 916,increments a counter for each outcome generated. The counter may beimplemented in either software or hardware. Furthermore, in step 918,the slot machine compares the number of plays stored in the flat ratedatabase to the value of the counter. If the value of the counter equalsthe stored number of plays, then the flat rate play session isterminated.

Turning now to FIG. 13, a flow diagram of a method 1300 for receiving apayout according to some embodiments is shown. As shown as step 1310,the flat rate play session generally ends upon the termination of thecountdown. Specifically, as shown in step 1312, the slot machine CPUterminates the flat rate play session by reconfiguring the slot machineto its default values. For example, the CPU resets the pay combinationstatus field in the payout table to reflect the original jackpotstructure. The CPU also generates a signal indicating that coins must bereceived for each play. In short, the player selected price parametersare no longer in effect.

In step 1314, the CPU checks the total credits accumulated, as stored inthe RAM, and transmits a payout command to a hopper controller (such asthe hopper controller 240 of FIG. 2A). Consequently, in step 1316, theslot machine pays out the total number of credits to the player.

An alternate embodiment of the present invention will now be describedwith reference to FIG. 15. In FIG. 15, for example, a flow diagram of amethod 1500 according to some embodiments is shown. The operation of theslot machine 102, 202 of FIG. 1, FIG. 2A, and/or FIG. 2B, may beindicated by the steps 1510-1524 of the method 1500, and proceedsgenerally as described with reference to FIG. 14. In this embodiment,the player selects from a list of casino determined price packages,rather than choosing individual price parameters. Each price package, asmay be stored in the flat rate price package database 229, 1429 of FIG.2A and/or FIG. 14, is a combination of different price parameters thatcorrespond to a flat rate play session price.

In step 1510, the player presses a “flat rate play” button on the slotmachine. The slot machine CPU receives a flat rate play signal from theplayer interface in step 1512. In this case, the player interface is anactual “flat rate play” button located on the outside of the slotmachine. Next, in step 1514, the CPU accesses the flat rate pricepackage database from data storage device 224 of FIG. 2A. The CPU thendisplays the player selectable price packages on video display area instep 1516. It is to be understood that the CPU need not display thepackages on the video display area, as those package options could bedisplayed elsewhere on the body of the slot machine. Alternatively, theplayer interface could incorporate several “flat rate play” buttons,each representing a different flat rate price package.

Next, in step 1518, the player selects the desired price package via theplayer interface. Having already seen what the price of the selectedpackage is, the player then deposits the appropriate amount of moneyinto the coin acceptor in step 1520. For example, the player may havechosen a price package identified by the number four (4) in the packageID field 1410 of FIG. 14, the package costing fifty dollars ($50). Inreturn for fifty dollars ($50) deposited into the slot machine, theplayer receives two hundred and fifty (250) handle pulls, with three (3)coins wagered per pull, and with the top three (3) jackpots active inhis flat rate play session. These parameters are specified in the flatrate price package database 1429 of FIG. 14.

In step 1522, the CPU receives an indication of payment from the coinacceptor and reconfigures the parameters of slot machine to meet thespecifications of the flat rate price package selected by the player.Finally, in step 1524, flat rate play begins.

It is noted that the flat rate price package database could be locatedat the slot network server and not at each individual slot machine. Whenit is located at the server, certain casino or operator selectedparameters could be used to determine the price. For example, therecould be different flat rate price packages for different times duringthe day that are based on projected or actual casino traffic and/or slotmachine usage.

As will be appreciated by one of ordinary skill in the art, the key stepin getting players to wager money on gaming devices, such as slotmachines, is to bring the players to the casino floor. One way in whichcasinos can bring additional players to the casino floor, and therebyincrease total revenues, is by giving away free samples or rewards witha minimum displacement of traditional pay per play players. Some presentembodiments may be employed for such a purpose.

In one embodiment, for example, the casino could declare a free playperiod. During the free play period, likely chosen by the casino tocorrespond to down time, when most gaming devices are idle, playersinsert their player tracking cards into the gaming devices and initiateplay without being charged. Specifically, the casino programs thecalculation table so that the flat rate price is zero for a given timeof day and day of the week. It is anticipated that during such a freeplay period, the casino will alter the jackpot structure, causing only aselected jackpot to be active. Thus, the lure of free jackpots willbring additional players to the casino floor that will likely continueplaying after the free play period ends. A further benefit of thisembodiment is that it would encourage players to become slot clubmembers. This would result in an increase of players who return to thecasino and the customer base that the casino markets to throughmailings.

It is also to be understood that play of the slot machines during thefree play period need not occur as described above. Thus, in analternate embodiment, the reels 232, 234, 236 of the slot machines 102,202 of FIG. 1, FIG. 2A, and/or FIG. 2B continuously spin, regardless ofwhether a player has inserted a tracking card, with the slot networkserver periodically signaling a jackpot on a random machine. Only when aplayer has inserted a player tracking card is the jackpot awarded. Theslot network server randomly selects a machine ID number and, if themachine is not being played by a pay-per-play player, the slot networkserver transmits a signal to that slot machine directing it to produce awinning outcome.

In an alternate embodiment that achieves substantially the same resultof attracting additional players to the floor during down times, thecasino issues guests a player tracking card or a smart card having apredetermined free credit balance associated therewith. The casino couldthen restrict the day and time in which the players could use the freecard in a flat rate play session. In another embodiment, the cardsprovided to guests contain an indication of time, rather than money, foruse during a flat rate play session.

Although the foregoing embodiments employ static jackpot structure,which stay the same throughout the flat rate play session, it is withinthe scope of some embodiments to employ dynamic jackpot structures,which change during the flat rate play session. In one such embodiment,the dynamic jackpot structure starts with a given number of activejackpots, as indicated in the pay combination status field 650 of thepayout table 628 of FIG. 6. As the flat rate play session progresses,the number of active jackpots changes. Specifically, as the intervalremaining in the flat rate play session decreases, fewer paycombinations are made active. In other words, the slot machine CPUmonitors the time and, every fifteen (15) minutes, for example, causesthe value of the pay combination status field 650 to change from“active” to “inactive” for a given pay combination. Alternatively, theCPU changes the value of the pay combination status field 650 after apredetermined number of plays. In a further variation of thisembodiment, individual jackpots may be decreased instead of or inaddition to being eliminated (e.g., the jackpot for a particular outcomemay decrease from ten (10) coins to eight (8) coins as the play sessionprogresses).

As will be appreciated by those skilled in the art, a dynamic jackpotstructure based on the time progression of the flat rate play sessioncan increase the revenue generated by the slot machines. Specifically,such a dynamic jackpot structure could be used with a flat rate playsession whose duration is not a fixed time, but rather a given number ofplays. Because fewer jackpots will be active as time progresses, playershave an incentive to use their fixed number of plays within a short timeperiod. Stated succinctly, some embodiments increases speed of play.

In another embodiment, the jackpot structure is dynamic based not on theprogression of the flat rate play session, but rather on the outcomesgenerated by the slot machine. One such embodiment involves changing aparticular jackpot from “active” to “inactive” upon a player hitting theoutcome corresponding to that pay combination. For example, a player maybegin the flat rate play session with all jackpots active. On one play,the slot machine generates a “CHERRY CHERRY CHERRY” outcome. Uponaccessing the payout table, the CPU determines that ten (10) coins areto be paid out, credits the player's accumulated credits accordingly,and causes the value of the pay combination status field 650 of FIG. 6corresponding to the “CHERRY CHERRY CHERRY” outcome to change from“active” to “inactive”. Thus, a player can only hit a given jackpotonce. As will be appreciated by those skilled in the art, such a dynamicjackpot structure will allow slot machine operators to further discountthe flat rate price to attract additional players. Furthermore, it isanticipated that players will be willing to forego hitting the samejackpot multiple times because their focus is typically on hitting thehighest jackpot once.

These and other dynamic jackpot structures may be implemented as eithera player selected price parameter or an operator selected priceparameter. When implemented as a player selected price parameter, thedynamic jackpot structure is displayed to the player as a playerselectable price parameter option. The player, in turn, selects it viathe player interface. When implemented as an operator selected priceparameter, the dynamic jackpot structure is displayed for player viewingprior to player approval of the flat rate price. Whether the priceparameters are selected by the player or the casino operator, thedynamic jackpot structure affects the flat rate price generally asdescribed above, namely, as a field in the calculation table or as avariable in the price algorithm.

In some embodiments, an individual may purchase a flat rate play sessionas a gift for another person. For example, an individual may purchaseone of the available flat rate price packages of FIG. 14. In such anembodiment the individual purchasing a flat rate play session may beprovided with a flat rate play session identifier, which the purchase inturn provides to the gift recipient. The flat rate play sessionidentifier may be stored by the casino in association with the priceparameters defining the flat rate play session. Thus, when the giftrecipient inserts the flat rate play session identifier into a gamingdevice, the gaming device may communicate with the casino server todetermine the parameters of the flat rate play session and set itself inaccordance with such parameters. A flat rate play session identifier maybe provided on, for example, a gift card that is magnetically oroptically encoded with the flat rate play session identifier such thatit may be read by a gaming device.

VI. Contract Embodiments

A. Introduction

In accordance with some embodiments, a flat rate play session may bepurchased by means of a contract. According to such embodiments a playerat a casino may purchase a contract (e.g., from an insurer, such as thecasino or another entity) or similar agreement to use a gaming device,such as a slot machine (e.g., the slot machines 102, 202 describedherein). Costing a fixed amount, the contract insures the player againstthe possibility of potentially large losses at the slot machine. Inaccordance with one such embodiment, upon purchasing the contract, aplayer credit account is set up at the slot machine. The account maybegin with zero credits but may begin with another balance in otherembodiments. The player is then allowed a fixed number of handle pulls(and/or a fixed amount of playing time) at the slot machine withoutrequiring the player to insert any money. Each handle pull decreases theplayer account, typically by decreasing the player account by apredetermined amount (e.g., one credit) for each handle pull. This maycause the number of credits to be negative, but play may still continue.If the player achieves a winning outcome, credits can be added to theplayer account in accordance with the payout for the winning outcome.If, after the fixed number of handle pulls (and/or the pre-determinedamount of playing time), there are a positive number of credits in theplayer account, then these may be paid out to the player in the form ofcash. If, however, there are less than a predetermined amount of credits(e.g., zero credits) in the player account, then the player receivesnothing. The insurer, however, could compensate the casino for, e.g., anamount in the players account that is less than a predetermined number.

In such an embodiment, the player enjoys the fixed number of pulls(and/or a fixed amount of playing time) without the risk of any loss.The only loss for the player comes from the cost of the contract.

One aspect of such embodiments is a way to price a contract for a blockof pulls to be sold to a player. Pricing a contract may involvecalculating the expected amount that would have to be paid a player uponthe completion of the pulls. The price of the contract would thentypically be greater than this expected amount (e.g., in the amount of aprofit margin) so as to result in an expected profit possibly to bedivided amongst the casino and, if it is a separate entity, an insurer.For example, if a player could be expected to receive thirty dollars($30) upon the completion of one thousand (1000) pulls, then thecontract for the block of one thousand (1000) pulls could by sold forthirty-five dollars ($35).

The following definitions generally define the terms used to describethe contract embodiments presented herein:

Contract indicator—an object or information by which a gaming device mayrecognize a contract in order to execute the contract. For example, aplayer purchases a contract at casino desk and receives a token thatserves as a contract indicator. When the player deposits the token in agaming device, the gaming device recognizes the contract the player hassigned up for and executes the contract accordingly.

Execute a contract—to carry out the terms of a contract. A gaming deviceexecutes a contract for two hundred (200) pulls by generating thehundred (200) outcomes, incrementing and decrementing player credits inaccordance with the outcomes, and paying the player, if necessary, atthe end of the contract.

Gambling contract—An agreement between a player, an insurer, andsometimes a casino (e.g., if different than the insurer) with thefollowing exemplary provisions:

-   -   The player pays the insurer a fixed amount up front.    -   The player must make a predetermined number of handle pulls, no        more and no less.    -   The player need not pay any additional money after purchasing        the contract.    -   The player keeps any net winnings after all handle pulls have        been completed.    -   If the player has a net loss after the handle pulls have been        completed, then the loss is paid to the casino by the insurer.

There are many variants of these provisions, and fewer or additionalprovisions are possible. As can be seen, the contract insures a playeragainst excessive losses, and may give the player more handle pullsand/or playing time than would otherwise be possible for the price ofthe contract. Also, since there may be no additional player decisionsrequired after the player has purchased the contract, the player neednot be present for the execution of the contract and may thereforeexperience the feeling of remote gambling.

Gaming Device—Any electrical, mechanical, or electromechanical devicethat accepts wagers, steps through a process to determine an outcome,and pays winnings based on the outcome. The outcome may be randomlygenerated, as with a slot machine; may be generated through acombination of randomness and player skill, as with video poker; or maybe generated entirely through player skill. Gaming devices may include,for example, slot machines, video poker machines, video blackjackmachines, video roulette machines, video keno machines, video bingomachines, and the like.

Gross winnings—the total of a player's winnings during the execution ofa contract without regard to wagers made by the player. For example, if,after five (5) pulls of a contract, a player has attained one (1)winning outcome with a payout of four (4) coins, and one (1) winningoutcome with a payout of twenty (20) coins, then the player's grosswinnings thus far are twenty-four (24) coins. Since gross winnings doesnot account for wagers a player makes, gross winnings will always belarger than or equal to net winnings.

Handle pull—a single play at a gaming device, including video poker,video blackjack, video roulette, video keno, video bingo, and otherdevices. The definition is intended to be flexible in that a single playmight constitute a single complete game, or a single wager. For example,in video blackjack, a player might play a single game in which he splitsa pair of sevens, requiring an additional wager. This single game mightthereby constitute either one (1) or two (2) handle pulls.

Net winnings—the total of a player's winnings during the execution of acontract minus the amount spent by the player on wagers. In the examplecited under the definition of “gross winnings,” the net winnings arenineteen (19) coins since the player has won twenty-four (24) coins butused one (1) coin as a wager on each of the five (5) pulls.

B. Description of the Contract

A typical contract is an agreement between the insurer and a player. Theplayer agrees to pay a fixed amount of money up front. In return, theplayer may (or must) gamble and/or play at a gaming device for adesignated amount of time or for a designated number of outcomes. Afterthe player has gambled the requisite amount, the player has the right tokeep any winnings that exceed a certain threshold. The player does not,however, pay any losses. Thus, one function of the contract is to insurethe player against losses at a gaming device. There are many variationsof the contract and a portion of these is described below.

Another function of the contract is to allow a player to play a largenumber of handle pulls without the need of a large bankroll. Forexample, a player wishing to make six hundred (600) pulls at a quarter($0.25) slot machine would ordinarily require one hundred and fiftydollars ($150; $0.25×600 pulls) in order to assure himself the abilityof completing the six hundred (600) pulls. However, a contract mightallow a player to make six hundred (600) pulls by paying, for example,only twenty dollars ($20).

In some embodiments, the contract does not involve an insurer. Thefunction of the contract may be to allow outcomes to be generated forthe player while the player is not physically present at the gamingdevice. In these embodiments, the contract may consist mainly ofinstructions from the player as to how the slot machine should gamble onthe player's behalf. For example, the instructions will tell the machinehow fast to gamble, when to quit, and then where to send winnings.

1. Amount of Play

A contract may place one or more of the following exemplary restrictionson play covered by the contract:

-   -   The player must make a minimum number of handle pulls.    -   The player may not make more than a maximum number of handle        pulls.    -   The player must play for a certain minimum time period.    -   The player must play for less than a certain maximum time        period.    -   The player must maintain a minimum rate of play.    -   The player may not exceed a maximum rate of play.    -   The total coin in over the course of the contract must exceed a        certain minimum amount.    -   The total coin in over the course of the contract must not        exceed a certain amount.    -   The player must play until obtaining a specified outcome.

2. Coin Denomination

A contract may also or alternatively specify the size of the wager foreach pull. The wager size may be the same as that typically used by thegaming device. For example, if a player signs up for a contract at aquarter ($0.25) slot machine, the wager for each pull of the contractmight be a quarter ($0.25). If the slot machine offers multiple coinbets, the wager for each pull might be a quarter ($0.25), fifty cents($0.50), seventy-five cents ($0.75), etc. The contract may allow or mayforce the player to vary the wager from pull to pull.

One aspect of a contract may allow all play to occur in credit mode.”That is, the player need not physically insert money into the gamingdevice prior to each pull, and money needn't come out of the gamingdevice after a player win. Rather, a player's credit balance may bestored in a player database either in the gaming device or at the casinoserver. Every time the player then makes a handle pull, credits arededucted from the player's balance. Every time the player wins, creditsare added to the player's balance. The player's credit balance can bedisplayed on the device so that the player may track his progress.

Since play may occur in credit mode, each wager might consist of coindenominations that are not standard for the gaming device. For example,a device that typically handles quarters may accept wagers of a nickel($0.05), of forty cents ($0.40), or even of twelve and one half cents($0.125).

3. Winnings Threshold

A contract may also or alternatively describe some threshold of grosswinnings, net winnings, and/or accumulated player credits above whichthe player keeps any excess. Gross winnings describe the accumulatedplayer wins from each pull of the contract. Thus, a player who makes sixhundred (600) pulls on a one dollar ($1) slot machine as part of acontract and wins three dollars ($3) on each of one hundred (100) pullshas gross winnings of three hundred dollars ($300; $3/pull×100 pulls).Net winnings are the gross winnings less the accumulated costs ofwagering. In the above example, the accumulated costs of wagering aresix hundred dollars ($600; $1/pull×600 pulls). Thus, in the aboveexample, the player's net winnings would be negative three hundreddollars (−$300; $300−$600). Accumulated player credits may mirror arunning tally of a player's net winnings. For example, a player maybegin with zero (0) credits, with credits deducted in the amount of anywager, and added in the amount of any winnings. Accumulated playercredits may also mirror a running tally of gross winnings, or any otherstatistic about a player's performance.

At the end of a contract, a player's accumulated credits may be comparedto a threshold. The player may then receive a payout of any excessaccumulated credits above the threshold. For example, if the thresholdis zero (0), and the player has forty-four (44) credits, each creditrepresenting twenty-five cents ($0.25), then the player receives apayout of eleven dollars ($11; 44 credits×25 cents/credit). If theplayer had negative twelve (−12) credits, indicating a net loss oftwelve (12) credits, then the player receives nothing. The player doesnot owe three dollars ($3) because the contract does not make the playerresponsible for any losses.

The threshold might be at ten (10) credits, in which case a player withaccumulated credits of thirty (30) would receive a payout equivalent totwenty (20) credits at the end of a contract, and a player with six (6)credits would receive nothing. A threshold might be at negative ten(−10) credits, in which case a player with accumulated credits ofnegative six (−6) would receive the equivalent of four (4) credits,while a player with negative one hundred (−100) credits would receivenothing.

Rather than insuring against all of a player's losses, a contract mightinsure all losses up to a point and not beyond. Therefore, a contractmay have multiple thresholds, each with different functions. A playermay, for example, be responsible for any losses beyond a threshold lossof one hundred (100) credits. The same player might receive any winningsbeyond a threshold of ten (10) accumulated credits. Thus, if, at the endof the contract, the player has accumulated negative one hundred andtwenty-five (−125) credits, then the player must pay twenty-five (25)credits. If the player has accumulated thirty-three (33) credits, thenthe player receives a twenty-three (23) credit payout. If the player hasaccumulated negative forty-nine (−49) credits, then the player neitherowes nor receives anything.

In some embodiments, a threshold delineates a change in the percentageof a player's winnings or losses between credit tallies above and belowthe threshold. For example, a player might keep any credits won beyond athreshold of fifty (50) Below fifty (50) credits, the player only keepseighty percent (80%) of his winnings. Therefore, if a player has seventy(70) credits remaining at the end of a contract, he keeps all twenty(20) credits above fifty (50), and he keeps an additional forty (40)credits, representing eighty percent (80%) of the first fifty (50)credits. Therefore, the player keeps sixty (60) credits in total.

A player may also be responsible for a percentage of losses above orbelow a certain threshold. For example, a player may be responsible forfifty percent (50%) of losses over ten (10) credits. Thus, a player whofinishes a contract with negative twenty (−20) credits owes nothing forthe first ten (10) credits of loss, but owes five (5) credits for thenext ten (10) credits of loss. The player therefore owes five (5)credits.

In the most general sense, a contract specifies a functionalrelationship between what a player's accumulated credits are at the endof the contracted number of pulls, and what the player either owes or isdue. The function may be piece-wise linear, or may be rather non-linearand convoluted.

Where there is potential for a player to owe money at the end of acontract, the player may be required to deposit money into the gamingdevice in advance so as to prevent the player from walking away when heowes money. The advance payment may later be returned if the playerturns out to owe nothing at the end of the contract.

In many embodiments, a contract is transparent to the casino. In otherwords, if the player makes a certain number of pulls, the casino makesthe same amount of money whether or not the player happened to beinvolved in a contract. In these embodiments, however, a casino maycollect money that it makes (and the player has lost) from the insurer,rather than from the player. The casino may also act as an intermediaryin transactions between the player and the insurer. For example, thecasino may collect from the player money that is meant to pay for acontract. The casino may then transfer an equivalent amount of money tothe insurer.

In other embodiments, a contract is not completely transparent to thecasino. That is, the amount of money a casino receives after a certainnumber of the player's handle pulls may depend on whether or not theplayer was in a contract. In one example, a casino agrees that if aplayer's accumulated credits at the end of a contract are less thannegative two hundred (−200), then the casino will only collect twohundred (200) credits for the contract's handle pulls. This example maybenefit the insurer, since the insurer doesn't have to worry aboutcovering player losses in excess of two hundred (200) credits. Inanother example, the casino configures a gaming device to give differentodds to a player in contract play versus a player not in contract play.

4. Player Decisions

As mentioned previously, players may have some restrictions on the playcovered by the contract. For example, a contract may cover an hour'splay at a gaming device, but require the player to make between sixhundred (600) and eight hundred (800) pulls in that hour. In someembodiments, however, contracts may allow players to quit early or toplay more than is otherwise covered by the contract. For example, acontract might cover an hour's worth of play. After the first half-hour,the player may be ahead by one hundred dollars ($100) and wish to quitwithout risking the loss of the one hundred dollars ($100) in thesubsequent half-hour. The player may therefore opt to pay twenty dollars($20), and/or some other determined amount, in order to be released fromthe obligation of continuing the contract. The player may then collectthe one hundred dollars ($100) in winnings.

A player at a gaming device may reach the end of a contract withaccumulated credits just short of an amount necessary to collectwinnings. However, the last seventeen (17) out of twenty (20) pulls mayhave been wins for the player. The player may feel as if there is somemomentum going and therefore may not wish that the contract be finished.In some embodiments, the player may extend the contract. For example,the gaming device might prompt the player, saying, “For only $5 more,we'll give you another 200 spins added to your contract.” If the playeraccepts, then the casino or insurer has made a new sale with potentialprofitability. In some embodiments, the player may be allowed to extenda contract for free, or may even be paid to extend the contract. Forexample, the player may have winnings of one hundred dollars ($100) atthe end of a contract. The casino, or insurer, may determined and/orestimate that if the player were to keep pulling, some of the onehundred dollars ($100) would likely be lost by the player. So the casinomay pay the player five dollars ($5), and/or some other determinedamount, to take another two hundred (200) pulls.

In a related embodiment, a player may carry over the accumulated creditsfrom a first contract to a second contract. Thus, a player with forty(40) accumulated credits at the end of a first contract may begin asecond contract with forty (40) accumulated credits. The player may payor be paid for carrying over credits.

5. Price

In many embodiments, the player pays a fixed sum to buy the contract. Inexchange for that fixed sum, the player can then gamble a significantamount with little or no risk of losses. In many embodiments, theinsurer takes the risk of the player's loss. The insurer must thereforeprice the contract so as to be compensated for the risk it takes. Inother embodiments, the casino and the insurer share the profits andlosses associated with a contract. To ensure a profit to be dividedamongst the two, a contract may be priced in excess of a player'saverage win. Note that a player's loss would generally count as zero (0)in figuring out the player's average win, since the player does not haveto pay for losses.

One method of pricing the contract involves first figuring out what theinsurer might expect to pay, on average, to cover a player's losses.Another method of pricing a contract involves first figuring out whatthe casino/insurer combination might expect to pay, on average, tocompensate a player for his winnings. Both methods may involve similarcomputations. Therefore, exemplary computations will be described below,at any given time, with respect to only one of many available methods ofpricing a contract.

Once the insurer and/or casino determine an expected cost, on average,to cover a player's losses pursuant to a flat rate play contract, theinsurer and/or casino may price the contract so as to provide a desiredprofit margin. For example, if the insurer and/or casino can expect topay, on average, fifteen dollars ($15) to cover a player's losses, thenthe insurer and/or casino might price the contract at twenty dollars($20) to insure a five-dollar ($5) average profit.

a) Exemplary Pricing Methods

(1) Reactive Pricing

In some embodiments, a casino and/or insurer may start with a firstprice for a contract, and then evolve the price as more and more of thecontracts are purchased and executed. For example, if an insurer losesmoney on the first few contracts it sells, then it may increase theprice of the contract for future sales. If the insurer makes largeprofits on its first few contracts, then it may reduce the price. Insuch a manner, for example, flat rate play contracts may be pricedreactively based on actual contract costs historically experienced bythe casino and/or insurer. According to some embodiments, a device suchas a gaming device and/or server may be utilized to automaticallyanalyze actually realized contract costs to determine expected futurecosts associated with contracts.

(2) Simulation

In some embodiments, flat rate session play pursuant to a contract(e.g., as defined by one or more parameters described herein) may besimulated to determine an expected cost of the contract. Such simulationmay take many forms including, but not limited to manual and/orautomatic gamin device testing and/or software-based gaming devicetesting (e.g., virtual testing).

According to some embodiments for example, the insurer and/or casino mayobtain a gaming device and/or a component of a gaming device containingsignificant information about the operation of the gaming device (e.g.,the CPU and/or memory). The insurer and/or casino then operate thegaming device as a player would when playing under a contract. Forexample, if the insurer is to sell contracts for six hundred (600)pulls, the insurer would make six hundred (600) handle pulls at thegaming device and record the number of accumulated credits at the end ofthe six hundred (600) pulls. The insurer may repeat this process oftesting contracts at the device for a large number of trials. Theinsurer may then average the simulated payments over all the trials.Note that while it might take a player days or years to complete, say,one hundred thousand (100,000) contracts at a gaming device, the processmay be sped up for the insurer by giving the gaming device specialinstructions to generate outcomes more rapidly. The performance of suchlarge numbers of trials in the manner described above is often called aMonte-Carlo simulation.

The following is an example of pricing a contract via simulation. Usinga simulation process, an insurer simulates the execution of a sixhundred (600) pull contract. The insurer repeats the simulation four (4)more times. After the first simulation, the player has won ten dollars($10). After the second, the player has lost five dollars ($5). Afterthe third, the player has lost seventeen dollars ($17). After thefourth, the player has lost eight ($8). After the fifth, the player haswon three ($3). To figure out what the insurer must pay, on average, theinsurer adds the three (3) losses to get: five dollars ($5)+seventeendollars ($17)+eight dollars ($8)=thirty dollars ($30). The insurer thendivides by five (5), the number of simulations, to get: thirty dollars($30)/five (5)=six dollars ($6). It is not generally important, for thepurposes of this calculation, how much the player won when wins weremade, since the casino is the one paying the player the winnings. Now,in order to obtain an average four ($4) profit, for example, the insurermight charge ten dollars ($10) for each contract.

In some embodiments, the insurer obtains or creates software thatmirrors or models the operation of the gaming device. For example, thesoftware is configured to generate the same outcomes, as does the gamingdevice with the same frequency as the gaming device. For each outcomegenerated, the software tracks what a player's accumulated credits wouldbe. As before, the insurer (and/or casino) may simulate many contractsand average the simulated payments over all the trials to determine anexpected average cost of the flat rate play contract.

(3) Mathematical Modeling

According to some embodiments, the insurer may mathematically modelpotential outcomes of one (1) handle pull of a gaming device using arandom variable with a Probability Mass Function (PMF) and/or aProbability Density Function (PDF). With these functions, the x-axis ofa graph may represent potential winnings, such as negative one dollar(−$1) or three dollars ($3), which can occur from a single handle pull.The example of negative one dollar (−$1) indicates the player has paidone dollar ($1) for the pull but has won nothing. The example of threedollars ($3) indicates that the player has paid one dollar ($1) for thepull and won four dollars ($4). The y-axis of the graph of thesefunctions represents the probability and/or probability density of eachoutcome occurring. The probability of the player getting negative onedollar (−$1) on a pull might be eight tenths (0.8), for example, whilethe probability of the player getting three dollars ($3) might be twotenths (0.2). A PMF for the number of accumulated credits at the end ofa contract can then be created by summing the random variablesrepresenting individual handle pulls. If each pull is independent withan identical PMF, as is common with gaming devices, then the PMF for theresults of the entire contract can be created using repeatedconvolutions of the PMF's for individual handle pulls. If, for example,six hundred (600) pulls are involved, then the PMF for single a handlepull may be convolved with itself five hundred and ninety-nine (599)times to generate a PMF for the entire contract. Using this resultantPMF, the insurer can easily calculate how much it would expect to pay tocover a player's losses on each contract. If the resultant randomvariable is denoted by “w”, and the insurer would by required to pay forany player losses, then the insurer's expected payment or cost is givenby “Formula (3)”, as:cost=Σ^(−∞)0w*probability(w).  (3)

In the mathematical simulation method described above, FourierTransforms, Z transforms, Laplace Transforms, and/or other transformscan be used to aid in the calculation of the repeated convolutions. Sucha use of transforms is well known in the art.

Also as is well known in the art, with many classes of random variables,repeated summation results in a Gaussian probability distribution. Thisdistribution has the shape of the familiar bell curve. The Gaussiandistribution has the advantage of being fully described by only twoparameters, a mean and a standard deviation. If a Gaussian probabilitydistribution is used to approximate the sum of a large number ofindependent, identically distributed random variables, such as thosethat often describe handle pulls, then the mean and standard deviationof the Gaussian distribution is very easily calculated based on the meanand standard deviation of a random variable describing an individualpull. Such calculations are well known in the art. Thus, a Gaussiandistribution can easily be generated to approximate the PMF of aplayer's accumulated credits at the end of a contract. Using thisdistribution, the insurer can calculate the amount it would be requiredto pay, on average, to cover a player's losses. The method ofcalculation is similar to that already described. If a Gaussian PDF isused as an approximation, then an integral sign replaces the summationsign, and “probability” is replaced by “probability density.”

The following is an example of using a Gaussian probability densityfunction to approximate the amount a casino would be required to pay, onaverage to, to compensate a player for his winnings at the end of acontract. The contract may then be priced in excess of this amount toensure an average profit for the casino/insurer combination. A Gaussianfunction is given by “Formula (4)”, as:f(x)=1/√(2πσ)exp(−(x−μ)²/(2σ²))  (4)

In “Formula (4)”, “σ” is the standard deviation, and “μ” is the mean.Now, let us suppose that a single handle pull of a slot machine resultsin a required payout to the player described by a probability massfunction with mean “μ₀” and standard deviation “σ₀”. Then, assuming eachhandle pull is independent, “n” handle pulls of the slot machine may bedescribed by a function with mean “μ=μ₀n” and standard deviation“σ=σ₀√n”. Furthermore, if “n” is large, then the function describing acasino's aggregate payout after “n” handle pulls may be approximated bythe Gaussian function “f(x)”, defined by “Formula (4)”.

To calculate what a casino would have to pay to compensate a player forhis winnings, on average, we note that the casino pays when the playerwins, but receives nothing when a player loses. Therefore, the expectedpayment of the casino is given by “Formula (5)”, as:∫_(−∞) ⁰0*f(x)dx+∫ ₀ ^(∞) x*f(x)dx=∫ ₀ ^(∞) x*f(x)dx.  (5)

We proceed to solve the integral: $\begin{matrix}{{\int_{0}^{\infty}{x^{*}{f(x)}\quad{\mathbb{d}x}}} = {\int_{0}^{\infty}{x^{*}{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}\quad{\mathbb{d}x}}}} \\{= {{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\int_{0}^{\infty}{x^{*}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}\quad{\mathbb{d}x}}}}} \\{= {{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\int_{0}^{\infty}\left\lbrack {{\left( {x - \mu} \right)^{*}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}} +} \right.}}} \\{\left. {\mu^{*}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}} \right\rbrack{\mathbb{d}x}} \\{= {{2{\sigma^{2}/\left. \sqrt{}\left( {2{\pi\sigma}} \right)^{*} \right.}{\left( {{- 1}/2} \right)^{*}\left\lbrack {\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)} \right\rbrack}_{0}^{\infty}} +}} \\{\mu{\int_{0}^{\infty}{{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}\quad{\mathbb{d}x}}}}\end{matrix}$

We deal with the two terms separately:${2{\sigma^{2}/\left. \sqrt{}\left( {2{\pi\sigma}} \right)^{*} \right.}{\left( {{- 1}/2} \right)^{*}\left\lbrack {\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)} \right\rbrack}_{0}^{\infty}} = {{{- \sigma^{2}}/\left. \sqrt{}{\left( {2{\pi\sigma}} \right)^{*}\left\lbrack {0 - \left( {{- \mu^{2}}/\left( {2\sigma^{2}} \right)} \right)} \right\rbrack} \right.} = {{\sigma^{2}{{\exp\left( {{- \mu^{2}}/\left( {2\sigma^{2}} \right)} \right)}/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}} = {{n\quad\sigma_{0}^{2}{{\exp\left( {{- n^{2}}{\mu_{0}^{2}/\left( {2n\quad\sigma_{0}^{2}} \right)}} \right)}/\left. \sqrt{}\left( {2\pi\left. \sqrt{}n \right.\quad\sigma_{0}} \right) \right.}} = {n^{3/4}\sigma_{0}^{3/2}{{\exp\left( {{- n}\quad{\mu_{0}^{2}/\left( {2\sigma_{0}^{2}} \right)}} \right)}/\left. \sqrt{}\left( {2\pi} \right) \right.}}}}}$and${\mu{\int_{0}^{\infty}{{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}\quad{\mathbb{d}x}}}} = {{\mu{\int_{{- \mu}/\sigma}^{\infty}{{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\exp\left( {{- y^{2}}/2} \right)}\sigma\quad{\mathbb{d}{y\left( {{{where}\quad y} = {\left( {x - \mu} \right)/\sigma}} \right)}}}}} = {{\mu\left. \sqrt{}\sigma \right.{\int_{{- \mu}/\sigma}^{\infty}{{1/\left. \sqrt{}\left( {2\pi} \right) \right.}{\exp\left( {{- y^{2}}/2} \right)}\quad{\mathbb{d}y}}}} = {\mu\left. \sqrt{}{\sigma\left\lbrack {1 - {\int_{- \infty}^{{- \mu}/\sigma}{{1/\left. \sqrt{}\left( {2\pi} \right) \right.}{\exp\left( {{- y^{2}}/2} \right)}\quad{\mathbb{d}y}}}} \right\rbrack} \right.}}}$

The integral is the cumulative distribution function for a zero mean,unit standard deviation Gaussian, for which tables exist. We denote itby “N(−μ/σ)”. Continuing:${\mu{\int_{0}^{\infty}{{1/\left. \sqrt{}\left( {2{\pi\sigma}} \right) \right.}{\exp\left( {{- \left( {x - \mu} \right)^{2}}/\left( {2\sigma^{2}} \right)} \right)}\quad{\mathbb{d}x}}}} = {{\mu\left. \sqrt{}{\sigma\left\lbrack {1 - {N\left( {{- \mu}/\sigma} \right)}} \right\rbrack} \right.} = {{n\quad\mu_{0}n^{1/4}\left. \sqrt{}{\sigma_{0}\left\lbrack {1 - {N\left( {{- n}\quad{\mu_{0}/\left( {\left. \sqrt{}n \right.\quad\sigma_{0}} \right)}} \right)}} \right\rbrack} \right.} = {n^{5/4}\mu_{0}\left. \sqrt{}{\sigma_{0}\left\lbrack {1 - {N\left( {{- \left. \sqrt{}n \right.}\quad{\mu_{0}/\sigma_{0}}} \right)}} \right\rbrack} \right.}}}$

Recombining the two terms we get “Formula (6)”, as:∫₀ ^(∞) x*f(x)dx=n ^(3/4)σ₀ ^(3/2)exp(−nμ ₀ ²(2σ₀ ²))/√(2π)+n^(5/4)μ₀√σ₀[1−N(−√nμ ₀/σ₀)]  (6)

If we were to graph the above as a function of “n”, the number of pulls,we would see that initially, as the number of pulls in a contract getslarger, a casino could expect to pay more money to compensate a playerfor his winnings. However, there would reach a point, beyond which morepulls in a contract would actually decrease the amount a casino couldexpect to pay to compensate a player for his winnings. This illustratesan important feature of contracts. Having more pulls in a contract isnot necessarily an advantage for a player.

(4) Reverse or “Budget”Pricing

In some embodiments, a gaming device and/or server may alternately oradditionally be configured to determine parameters of a contract orsession based on a player-requested price (and/or other player-definedparameter). Referring to FIG. 16, for example, a flow diagram of amethod 1600 according to some embodiments is shown. In some embodiments,the method 1600 may begin at 1602 by receiving an indication of a pricea player is willing to pay for flat rate play at a gaming device. Forexample, a player may choose a price from a menu and/or enter or definea price that the player would like to pay for flat rate play at a gamingdevice. According to some embodiments, this “budget” may simply bedefined as a number of credits that the player has accrued and/orentered into a gaming device. In some embodiments, the “price” may infact comprise a definition of one or more parameters (and/or valuesthereof), which may or may not include a price parameter. A player mayspecify and/or indicate, for example, that the player wishes to play fora flat rate for a specific amount of time (e.g., the player wishes toplay for ten minutes (10-min), such as the amount of time until a showstarts).

The method 1600 may then continue, at 1604 for example, by determining adesired profit of the flat rate play at the gaming device. The gamingdevice and/or server may lookup a stored indication of a desired profitmargin and/or profit rate to be associated with the gaming device, flatrate play contracts or sessions, particular games, etc. In someembodiments, such a desired profit may be set, defined, and/orestablished or managed by an operator. According to some embodiments,the desired profit may be determined (e.g., looked-up and/or calculatedor algorithmically-defined) dynamically and/or in real time (e.g., basedon stored rules, current machine usage, time of day, and/or otherfactors).

According to some embodiments, the method 1600 may continue bycalculating, based at least upon the price and the desired profit, atarget cost for the flat rate play at the gaming device, at 1606. Thetarget cost for the flat rate play may, for example, simply be the price(e.g., retail price) of the session or contract less a profit margin. Inthe case that the desired profit is expressed in terms of a desiredprofit rate, the desired profit margin may be derived by multiplying therate by a duration of the flat rate play (e.g., time and/or number ofplays). In some embodiments, multiple durations may be tested and/oranalyzed to determine the target cost to be associated with a desiredprofit rate. Pre-determined durations in intervals of half an hour maybe multiplied by the desired profit rate, for example, to derive variousdesired profit margins for the different durations. Target costs maythen be determined for each of the flat rate play durations. Accordingto some embodiments, the target cost and/or other metrics may simply beretrieved from memory and/or looked up via a table.

In some embodiments, the method 1600 may continue at 1608 by determininga flat rate play session with an expected cost substantially equal tothe target cost, wherein the flat rate play session is defined by one ormore parameters. The gaming device or server may utilize the target costto query a database of available flat rate play sessions or contracts,for example. According to some embodiments, the expected cost of flatrate play sessions or contracts may be determined, such as via any ofthe methods described herein. In some embodiments, the one or moreparameters may be determined. Instead of retrieving flat rate playsessions with expected costs substantially matching the target cost(and/or costs), for example, different values for one or more sessionparameters may be tested to determine which combinations of values forthe parameters may result in expected session costs substantially equalto the target cost. In some embodiments, such an analysis (and/orretrieval from memory) may result in a plurality of available flat rateplay sessions and/or contracts that have expected costs thatsubstantially match the target cost. Rules and/or algorithms may then beused, for example, to determine which of the flat rate play session s orcontracts to offer to the player. In such a manner, for example, theplayer may simply define a “budget” that the player wishes to utilizefor flat rate play at a gaming device, and the parameters of theparticular flat rate play session or contract may then be determined andoffered to the player. In some embodiments, the player may be allowed tochoose between a plurality of available sessions or contracts havingdifferent parameters (and/or values thereof) but generally havingsimilar prices (e.g., substantially equivalent to the player's “budget”,or at least less than the player's budget). It should be understood thatdifferent games and/or game types may yield quite different parametersfor the same or similar retail price. One game may be available for a“budget” price and comprise one hundred (100) plays, spins, or hands,for example, while another game may be available for the same price yetmay comprise four hundred (400) plays, spins, or hands. In someembodiments, such as in the case that the player's budget is too low,the closest session with a price higher than the budget may be offeredto the player provided the player provides the difference between thebudget and the session price (e.g., by depositing more coins orcredits).

The method 1600 may continue, according to some embodiments, byinitializing play of the flat rate play session in accordance with theone or more parameters, at 1610. In the case that the player accepts theoffer for the automatically defined session, for example, the gamingdevice and/or server may automatically initiate the accepted flat rateplay session or contract. In some embodiments, the session may only beinitiated or deemed accepted once the player provides the “budget”price. In the case that the price is based on credits already availableto the player via the gaming device, the credits may automatically bemade available to purchase the accepted flat rate play session orcontract. In some embodiments, the player may automatically accept thedevice-determined session before determination of the parameters (orsome parameters). After winning, providing, and/or accruing a certainamount of credits at a gaming device, for example, the player mayindicate (e.g., via a menu) that the player wishes to purchase a flatrate play session of a certain duration (or minimum duration) for theamount of available credits. The player may commit to the purchaseprovided that the automatically determined session or contract meets oneor more criteria specified by the player (such as the minimum duration,a certain wager amount per play, etc.).

As an example of such reverse or “budget” pricing and/or parameterdetermination, a player may simply approach a gaming device, enter(e.g., using a keypad) or select (e.g., by pressing an icon of atouch-sensitive display screen) a particular price, and a gaming devicemay then output a menu of available contracts or sessions based on theprice. For example, for a retail price of twenty dollars ($20), a casinomay be willing to offer any contract with a contract cost of fifteendollars ($15) or less. Further, in one example, based on the pricerequested by a player and an hourly profit rate specified by anoperator, a gaming device and/or server may be configured to determineappropriate parameters of a “custom” contract. For example, if a playerenters a price of seventeen dollars ($17), and an operator has entered adesired hourly profit rate of nine dollars ($9), the player may beoffered a variety of thirty-minute (30-min) contracts or sessions withassociated expected costs of four dollars ($4), one-hour (1-hr)contracts or sessions with associated expected costs of eight dollars($8), and/or forty-five-minute (45-min) contracts with associatedexpected costs of six dollars ($6). In this manner, the retail price ofa gaming contract or flat rate play session may be determined. A playermay then purchase the gaming contract or flat rate play session asdescribed herein, and play within the contract or session may commence.

b) Pricing Examples

Flat-rate game play gives a player a fixed amount of time and/or numberof plays, of a particular game. Conversion between fixed time and fixedplays involves simply specifying a rate of play. For example, given anexpected rate of play of five hundred (500) hands of video poker perhour, selling two hundred and fifty (250) hands or thirty (30) minutesamounts to the same thing. The methodology described here provides for adetermination of the contract cost for a fixed number of hands. Given anexpected rate of play, it is straightforward to convert the number ofhands into a fixed period of time.

Flat-rate play, as opposed to conventional (or “transactional”) play,guarantees the player that they will not pay any more than the retailprice of the session. In other words, the players' net losses areabsorbed by the casino and/or insurer. Any net win for the session,however, is still paid out. The contract cost of a session is,generally, the expected amount of money, on average, that the casinowill have to pay each player. The price of the flat rate play sessionand/or contract may then simply comprise the expected cost plus a profitmargin, as described herein.

(1) Parameter-Based Pricing Example

In many embodiments, prices of various flat rate sessions or contractsmay be determined based on a variety of associated parameters, such asthe duration of the contract, the wager amount per game play, thestarting balance of the contract, active payouts associated with thecontract, and so on. Any of various available pricing methods (such asthose described herein) may, for example, be utilized to price contractsdefined by one or more contract parameters.

For example, in one or more embodiments, an operator (e.g., a casinoand/or an insurer) may calculate (e.g., by way of repeated mathematicalsimulation) the average amount expected to be paid out to a player of agaming contract when the contract comprises various parameters. Forexample, it may be determined that the average “contract cost” (e.g.,the average amount paid out to players upon resolution of a gamingcontract) is ten dollars and three cents ($10.03) for a draw video pokercontract characterized by the following parameters:

-   -   Contract duration/interval: thirty (30) minutes or two hundred        and fifty (250) hands of draw poker    -   Wager amount per hand: twenty-five cents ($0.25)    -   Starting balance: zero (0) credits (each wager deducts one (1)        credit, such that the player's balance can be negative)    -   Active pay combinations: Royal Flush pays four thousand (4,000)        credits, Straight Flush pays fifty (50) credits, Four of a Kind        pays twenty-five (25) credits, Full House pays nine (9) credits,        Flush pays six (6) credits, Straight pays four (4) credits,        Three of a Kind pays five (5) credits, Two Pair pays two (2)        credits, Jacks or Better pays one (1) credit    -   Threshold above which player may collect winnings: zero (0)        credits

Thus, after simulating play of a gaming contract with the aboveparameters, it may be determined that the following expression is true:$\frac{\begin{matrix}\left( {{Total}\quad{number}\quad{of}\quad{players}\quad{finishing}\quad{with}\quad a\quad{positive}\quad{{balance} \cdot}} \right. \\\left. {{Average}\quad{amount}\quad{won}\quad{by}\quad{players}\quad{with}\quad a\quad{positive}\quad{balance}} \right)\end{matrix}}{{Total}\quad{number}\quad{of}\quad{players}} = {{\$ 10}{.03}}$

Accordingly, as described, this contract cost (or base price) may beused to calculate a retail price (e.g., a flat rate price to be paid byplayers when purchasing a gaming session). For example, an operator maymultiply the contract cost by a desired margin to arrive at a retailprice (e.g., $10.03·1.5=$15.05, establishing a fifty percent (50%)profit margin). In other embodiments, an operator may calculate a retailprice by adding a fixed amount to a contract cost (e.g., each contractshould be priced ten dollars ($10) above the contract cost).

Thus, in some embodiments, an operator or other party may set retailprices in association with a number of gaming contracts before suchcontracts are made available to players, such that the prices may remainfixed so long as the contracts are offered (e.g., before a video pokermachine offering a “Play by the Hour” feature is released to the public,it is determined that thirty (30) minutes of video poker play, whereinplayers wager twenty-five cents ($0.25) per hand, may cost the playertwenty dollars ($20), yielding an expected ten dollars ($10) in profitper contract).

(2) Simulating ‘Perfect-Play’ Example

In some embodiments, a probabilistic approach may be utilized todetermining the contract cost. In this example, the expected contractcost of a two hundred and fifty (250) hand session of “9/6 Jacks orBetter” video poker, played at max coin (five (5) coins) on aquarter-denomination ($0.25) machine is simulated. With perfect-play, aplayer can expect a return of ninety-nine and fifty-four one hundredthspercent (99.54%) at “9/6 Jacks or Better” playing max coin. This hasbeen extensively analyzed, and the probability of achieving each type ofhand is summarized in Table A as follows: TABLE A “9/6 Jacks or Better”‘Perfect-Play’ Paytable Cycle 100,000,000 5-coin Payout Per-Coin PayoutFrequency Probability Expected Value Odds Royal Flush 4000 800 24760.002476% 0.019808 1 in 40,388 Straight 250 50 10930 0.010930% 0.0054651 in 9,149 Flush Four of a 125 25 236256 0.236256% 0.059064 1 in 423Kind Full House 45 9 1151222 1.151222% 0.10360998 1 in 87 Flush 30 61101450 1.101450% 0.066087 1 in 91 Straight 20 4 1122925 1.122925%0.044917 1 in 89 Three of a 15 3 7444867 7.444867% 0.22334601 1 in 13Kind Two Pair 10 2 12927900 12.927900% 0.258558 1 in 8 Jacks or 5 121458500 21.458500% 0.214585 1 in 5 Better Nothing 0 0 5454347454.543474% 0 1 in 2 Payback 99.54% Std. Dev. 4.42

These probabilities can be used to simulate how a player's balance couldchange while playing perfect “9/6 Jacks or Better”. For example, Table Ashows that on any given hand, there is a fifty-four and fifty-four onehundredths percent (54.54%) probability of a player losing an entirebet, a twenty-one and forty-six one hundredths percent (21.46%)probability of breaking even, a twelve and ninety-three one hundredthspercent (12.93%) probability of the player doubling the bet, etc. Withthis information, perfect-play “9/6 Jacks or Better” may be modeled asif it were a simple slot machine, where the per-pull probability of eachpayout is known. The benefit of simulating video poker in this way isthat it can be played very quickly—the outcome of each hand isdetermined by generating a random number and mapping it onto a table ofprobabilities; this requires significantly less computer instructionsthan direct modeling of decks, cards, strategy logic, etc., and yetproduces precisely the same results in terms of probabilities ofper-hand outcomes

To determine the contract cost of a two hundred and fifty (250) handsession of “9/6 Jacks or Better” (max coin) played perfectly, it isfirst decided how many sessions (e.g., players) to simulate. It has beenfound that simulations produce very consistent results if it is ensuredthat each simulation consists of at least fifty (50) million plays(where, in the case of video poker, one play is one hand). If youconsider that the least frequent event in video poker is generally theroyal flush, which pays out four thousand (4,000) credits at a frequencyof once every forty thousand, three hundred and ninety (40,390) hands,it will be seen that fifty (50) million hands is a large enoughsimulation to generate over twelve hundred (1,200) royal flushes, whichis generally enough to produce good probabilistic predictions. Wecalculate the number of sessions (players) required for each simulationby dividing fifty (50) million by the number of plays per session. Thus,for example, to determine the contract cost for a two hundred and fifty(250) hand session, we would simulate two hundred thousand (200,000)player sessions of two hundred and fifty (250) hands each.

To determine the final player balance for each session, we generate twohundred and fifty (250) random numbers, where each number is uniformlydistributed between zero (0.0) and one (1.0), map that range into theprobabilities of Table A, and thereby convert each random number to apayout. The sum of these payouts, minus the total amount wagered, is thefinal player balance for the session. (We subtract the wagers from thetotal payout because the game is played as if the wager were being made,even though all the wagers are, in effect, pre-paid.) If the balance isnegative, we essentially ignore it. It is irrelevant for the purposes ofcalculating contract cost, but we may still use it to determine otheraspects of the session (such as the players' subjective experience). Ifthe balance is positive, we add it to a running total of all positivebalances.

After running two hundred thousand (200,000) of these sessions, we knowthe total amount of money required to pay off all players in thesimulation with positive balances. If we divide this total by the numberof players (two hundred thousand (200,000) in this case), we arrive atthe expected contract cost. In other words, the expected contract costis the dollar amount required to pay off the players with positivebalances, averaged over all players (assuming each player started thesession with a balance of zero (0) credits).

Once the expected contract cost is known, it can be used to drivepricing decisions. For instance, a contract cost of seventeen dollarsand fifty cents ($17.50) might suggest a retail price of thirty dollars($30). In this case, we would expect an average profit of twelve dollarsand fifty cents ($12.50) per session (e.g., the profit margin).

Contract costs for less-than-perfect play, or floor play, may also oralternatively be simulated. To do this, we reduce the payback of thegame by two percent (2%) by increasing the probability of the mostfrequent payout (0) at the expense of the next most frequent payout (1).If necessary, we move to successively less frequent payouts until wereach the desired payback. This procedure minimizes any change to thestandard deviation of the payouts, which, has been found, has a stronginfluence on contract cost.

(3) Early Cashout Example

According to some embodiments, some of the profitability of a flat rateplay contract and/or session comes from the fact that, probabilisticallyspeaking, in a negative expectation game, the longer the player stays onthe device, the lower their final balance will be. We generally refer tothis principle as gravity, in a negative expectation game, gravity willeventually bring the player down. But what would happen if playersemployed a “quit-while-you're-ahead” strategy such that they cashed outas soon as they reached a target balance above their buy-in amount (forexample, twice or three times the buy-in amount—or even exactly thebuy-in amount)? Would players employing such a strategy be able to“beat” the expected profitability of a flat rate play contract,defeating gravity by cashing out before it can overtake them again?

To examine the effect of such a strategy, several simulations may berun, having the player cash out when their balance reaches aconfigurable multiple of their buy-in amount. Simulations may also berun to see what would happen if the player cashed out as soon as theyhit the jackpot (in the case of “Jacks or Better”, a royal flush, or inthe case of “Double Double Bonus”, a royal flush or any of the bonusquad payouts). Such simulations may show, for example, that earlycash-out has some effect on contract cost, but that such effect variesdepending on the game, and also depending on whether perfect-playstrategy is employed. In general, however, the maximum effect of earlycash-out on contract cost may be found to be only a little more than onedollar ($1) per half-hour of play (e.g., two hundred and fifty (250)hands at five hundred (500) hands per hour).

For example, consider two hundred and fifty (250; e.g., half an hour) of“Double Double Bonus”, played optimally, with a retail flat rate playprice of forty-five dollars ($45). Without cashing out early, thecontract cost may be determined to be thirty-six dollars and ninety-fourcents ($36.94). If players cash out as soon as they cross their buy-inamount of forty-five dollars ($45), then they actually do slightlyworse, bringing the contract cost down to thirty-six dollars andsixty-one cents ($36.61). But if they cash out at ninety dollars ($90;e.g., twice their buy-in), they do a little better, for a contract costof thirty-seven dollars and sixty-one cents ($37.61). For “Double DoubleBonus”, played optimally, all other cash-out triggers (one and a half(1.5) times the buy-in, i.e., “1.5×”; “2×”, “2.5×”, “3×”, “3.5×”, “4×”,“4.5×”, “5×”, and jackpot) may generally yield values between thirty-sixdollars and thirty-four cents ($36.34) and thirty-seven dollars andsixty-one cents ($37.61). For this game then, at optimal play, theplayer does best by cashing out at twice (“2×”) their buy-in, but theimpact on the profitability of the game may be extremely minimal. In thepresent example, for instance, the profit made by the flat rate playcontract (e.g., for a casino and/or insurer) may only vary between a lowof seven dollars and thirty-nine cents ($7.39) and eight dollars andsixty-six cents ($8.66), a range of merely one dollar and twenty-sevencents ($1.27). Such an example of simulated early cashout effects onprofitability are shown in Table B, below (with the highest and lowestexpected contract costs shown in bold). TABLE B “9/6 Double DoubleBonus” (Optimal Play) Early Cashout Number of Retail Cashout ContractProfit Per Hands Price Trigger Cost Contract 250 $45.00 $36.94 $8.06 250$45.00 1.0× $36.61 $8.39 250 $45.00 1.5× $37.57 $7.43 250 $45.00 2.0×$37.61 $7.39 250 $45.00 2.5× $37.40 $7.60 250 $45.00 3.0× $37.39 $7.61250 $45.00 3.5× $37.31 $7.69 250 $45.00 4.0× $37.05 $7.95 250 $45.004.5× $36.34 $8.66 250 $45.00 5.0× $36.89 $8.11 250 $45.00 jackpot $37.08$7.92

As a second example, consider “Jacks or Better”. In “Jacks or Better”,the best strategy the player can employ is to play through their sessionusing standard optimal strategy, with a contract cost of eighteendollars and nineteen cents ($18.19). If the player cashes out at threetimes (“3×”) their buy-in, they may achieve similar results with acontract cost of eighteen dollars and sixteen cents ($18.16). Thisdifference of three cents ($0.03) is arguably within the margin of errorof the probabilistic simulation, which can produce results that vary upto about seventy-five cents ($0.75) from run to run. This also serves toillustrate the point that players who cash out early may have an effecton the contract cost, but simulations indicate this effect to berelatively insignificant.

Further, these examples so far have been presented as using optimalplay. Many (even a majority) of players, however, do not have strategycards memorized, and typically play at about two percent (2%) belowoptimal. While effects on profitability may vary slightly in such cases,the effects will generally still remain relatively insignificant interms of overall profitability of flat rate play contacts.

6. Offering the Contract

A contract may be offered to a player in any number of ways. A gamingdevice may use text and/or synthesized voice to ask a person whether ornot he would like to sign up for a contract. A casino attendant mayoffer a contract to a player, or signs at a casino may point a playertowards a casino desk where he may then purchase a contract.

A number of circumstances may trigger the casino or an insurer to offera contract to the player. For example, the player may have lost most ofan initial stake deposited into a gaming device. A player may be slowinghis play, or may no longer be inserting coins into the machine. The timeof day may be a player's typical lunch time or departure time. A playermay have the opportunity to enter into a contract only if he also agreesto do business with a particular merchant or group of merchants. Theplayer may have the opportunity to enter into a contract if the casinoor insurer deems him a good, valuable, or loyal customer.

7. Agreeing to the Contract

A player may specify a desired contract in a number of ways. At a gamingdevice, a player may use a touch screen to indicate his desire to enterinto a specific contract. Using the touch screen, the player may selectfrom a menu of possible contracts. For example, the menu might listseveral contracts with different time durations or different prices. Theplayer could then select a contract by touching an area of the screennext to his desired contract.

The player might use menus to customize a contract for himself. Theplayer might use a first menu to select a duration of the contract(e.g., six hundred (600) pulls, or half an hour). A second menu might beused to select a rate of play. A third menu might be used for coindenomination. Many other menus are possible for other contract features.Once the player has selected several contract features, the gamingdevice may select the remaining feature so as to make the contractprofitable for the insurer. For example, once the player has chosen anumber of pulls and a coin denomination, the gaming device might choosethe price of the contract.

Rather than a touch screen, a player may use special buttons, keys, orvoice input to specify a desired contract or contract terms.

In some embodiments, a player chooses a contract prior to approachingthe gaming device or even the casino. A player might select a contracton the Internet. On the Internet, the player might specify terms of thecontract, such as the number of pulls, the rate of play, the cost, thepayout tables, the winning symbol combinations, etc. The player may thenprint out a code or a document describing the terms of the contract. Theplayer then brings the code or document to a gaming device that thenrecognizes what contract the player has chosen. When the player signs upfor a contract, a description of the contract might be sentelectronically directly to the gaming device. The player might then onlyidentify himself at the gaming device in order to initiate contractplay.

Other terms of a contract a player may agree to or specify include: thefont size of the machine, the noise level of the machine's soundeffects, the particular game (e.g., number of reels, number of paylines), the brightness of the display, etc.

8. Signature

To confirm entry into a contract, a player might sign a document thatmay contain the terms of the contract. The document may be printed froma gaming device or from the Internet, or may be obtained from a counterat a casino. The signed document may then be deposited into an openingin the gaming device, may be returned to a casino counter, or may bekept by the player. The player might also sign an area on a touch screenor other sensing device.

A player might also confirm entry into a contract simply by paying forit. The player might pay be depositing tokens, coins or other currencyinto the gaming device. The player might pay using a credit or debitcard. The player might also pay from a player credit account establishedwith the casino. The player might pay at a counter of the casino andmight receive a contract or a contract indicator to bring to a gamingdevice. The gaming device might then recognize the contract indicatorby, for example, a bar code, and then execute the contract.

9. Instruction Sets

A typical contract may cover and/or require a large number of handlepulls by the player. Now ordinarily, when a player is gambling at agaming device for a long period of time, the player makes a number ofdecisions related to his gambling. Should the player play more quicklyor more slowly? Should the player double his bet after a loss? Shouldthe player quit after a sizable win? Should the player take a shortbreak to use the restroom?

Since the contract covers a large number of pulls, it is possible forthe some player decisions to be made beforehand and included in thecontract. A gaming device may then act on the decisions specified in thecontract without further input from the player. For example, whilenegotiating a contract for an hour of play at ten (10) pulls per minute,a player might decide he'd like a fifteen-minute (15-min) break betweenthe first half hour and the second half hour of pulls. The gaming devicemight then execute the contract for the first half hour by automaticallyspinning and generating outcomes for the first half hour. The gamingdevice might then freeze for fifteen minutes (15-min), preventing otherplayers from stepping in and allowing the contract holding player totake his fifteen-minute (15-min) break. The device can then unlock afterfifteen minutes (15-min), perhaps with the entry of a password, andresume the generation of outcomes.

One important aspect of having a player's decisions spelled out beforehand in the contract is that the player need not even be present at thegaming device. A player can sign up for a contract at a casino in LasVegas, Nev., for example, and then have the contract executedautomatically by a gaming device. The player can then view a runningtally of his accumulated credits over the Internet while in Virginia,for example.

In general, player instructions built into a contract will include someaction to be performed as well as some triggering condition for theaction. As an example, a player instruction may be to increase the rateof handle pulls provided accumulated player credits exceed one hundred(100). In this example, the action is to increase the rate of handlepulls, and the triggering condition is whether accumulated playercredits exceed one hundred (100). The following player actions may bepart of a player's instructions:

-   -   Increase or decrease a wager amount on one or more handle pulls.    -   Increase or decrease a rate of wagering.    -   Cease gambling.    -   Change the way outcomes are displayed.

The following conditions may trigger the above actions

-   -   The player has just won or lost on one or more handle pulls.    -   The player has just won a certain amount on one or more handle        pulls.    -   Any player defined sequence of wins and losses has occurred on        prior handle pulls.    -   The player has approached or left the vicinity of the gaming        device.    -   The current time has reached a particular time of day.

One advantage of contracts executed by the gaming device is that agaming device can gamble at speeds a human is incapable of achieving.For example a player is on a winning streak, but must soon join hisfamily for lunch. Rather than cash out and leave, he decides toaccelerate his play to two pulls per second (2 pulls/sec). He thereforeenters a into a contract which is to be executed by the machine at twopulls per second (2 pulls/sec) for the next eight (8) minutes. In thiscontract, an insurer is not involved. The contract simply serves as ameans of increasing the rate of play. As it happens, the player may loseall his money in six (6) minutes, and so the contract ends.

Player instructions may tell the slot machine to play faster when theplayer is present or is observing in some way, and to play more slowlywhile the player is asleep. For example, the rate of pulls may be twiceas fast during the day as at night. The rate of play may likewise befaster when an infrared detector in the slot machine senses the heat ofthe player's presence.

Player instructions may also tell a gaming device how to play certaingames involving player decisions. For example, a player may leaveinstructions to use basic strategy in a game of video blackjack, or toplay according to published theory in a game of video poker. The playermay add instructions to always draw to a four card open-ended straightflush.

10. Times of Execution

A contract may be executed over a range of different time periods. Theoutcomes, the accumulated player credits, and the player winnings may ormay not be displayed to the player at the same time at which theoutcomes are being generated.

In one embodiment, all the outcomes needed for a contract are generatedvery rapidly by a gaming device, perhaps all in less than a second. Theoutcomes may then be displayed to the player over a much longer timeframe so as to give the player a more exciting gaming experience.

In another embodiment, outcomes may be continuously generated at a ratecomparable to that with which a player might make handle pulls on hisown. This embodiment might be entertaining for a player if the player issitting at the gaming device or watching the outcomes being generatedfrom a home computer.

In another embodiment, outcomes are generated on a periodic basis atfixed times every day, week, hour, etc. For example, outcomes for a sixhundred-pull (600-pull) contract may be generated one hundred (100)outcomes at a time, each block being generated from eight in the eveningto nine at night (8 PM-9 PM) on Sunday. Thus, it would take just undersix (6) weeks for the entire contract to be executed. This method ofexecution may be ideal if a player has a schedule as to when he enjoyswatching outcomes being generated. For example, the player might enjoyseeing outcomes generated while he watches his favorite show on Sundaysfrom eight in the evening to nine at night (8 PM-9 PM). This method ofexecution might also be ideal for the casino if slow business periodsoccur on a periodic basis where the entire contract cannot be executedin a single period.

In still another embodiment, outcomes are generated on a flexible basis,either when it is convenient for the casino or for the player. In thisembodiment, the casino may wait for a gaming device to be free of usebefore using it to generate the next couple of outcomes of a contract.Alternatively, the player may signal the gaming device any time he isready to have the next few outcomes generated

11. Viewing the Contract's Execution

As discussed, a player may enjoy watching from a remote location as theoutcomes of his contracts are generated. Since the player is notphysically at the slot machine, the outcomes must be presented to theplayer via some graphical representation. In one embodiment, a camerasimply films the gaming device generating the player's outcomes. Theimage from the camera is transmitted to the player device via theInternet, the cable system, satellite, etc. The player device might be,for example, a TV or a personal computer. In another embodiment, thegenerated outcomes are recorded either by the gaming device, by a camerawatching the device, or by a casino employee. The generation of theoutcomes is then graphically recreated for the player in a manner notnecessarily consistent with the physical appearance of the gaming devicethat generated the outcomes. For example, a gaming device generates theoutcome: cherry-orange-lemon. The gaming device then transmits, via thecasino server and the Internet, a bit sequence indicating the outcomescherry-orange-lemon. Perhaps the bits “0000” represent cherry, “0011”represent orange, and “1111” represent lemon. The bit sequence istransmitted to a player's home computer, where a software programdisplays a cartoon representation of a slot machine. The cartoon showsthe reels spinning and stopping with the outcome: cherry-orange-lemon.The cartoon representation of the slot machine may not look anythinglike the slot machine that originally generated the outcomes. In someembodiments, a player views a combination of the actual image of hisgaming device, and a computer-rendered version of a gaming device. Forexample, a cartoon of the reels spinning might be displayed within theframe of an actual image of the slot machine, without the reels.

In some embodiments, the player does not view a graphical representationof the outcomes, but sees the outcomes as text, such as “seven-bar-bar,”“s-b-b,” “7-b-b,” etc. The player may not even see the outcomes, justhow much he has won or lost on every pull. Thus, the player may view aperiodically updated tally of his accumulated credits. He may only viewhis total accumulated credits, or his take home winnings, after alloutcomes have been generated.

Any graphical or textual representation of the player's outcomes,accumulated credits, or other contract information may be displayedeither on an entire portion of a computer or TV screen, or on a smallerportion of the screen. For example, a small cartoon slot machine mayreside in a box in the upper right hand corner of a TV screen thatsimultaneously displays a regular TV show. A player watching televisionneed then only glance up at the corner of his screen to follow theprogress of his contract. Representation of outcomes may also be placein an email message to the player.

Of course, the various representations of outcomes may be used just aswell with a player physically present at the gaming device or at thecasino.

In some embodiments, the player calls up a number to monitor theprogress of his contract. He may enter a code or password when promptedby a Voice Response Unit (VRU) and thereby access the outcomes from hisparticular contract. A player may also receive a DVD from the gamingestablishment containing a representation of the game outcomes receivedby the player.

A player may be sent updates on his contract only when certaintriggering conditions are met. For example, a player may only wish forupdates when he wins more than one hundred (100) credits on a spin, orwhen the contract terminates.

12. Revenue Management

As discussed herein, the pricing of a contract will often take intoaccount the expected amount an insurer must pay to a casino to cover aplayer's losses, or the expected amount that a casino and insurer incombination can expect to pay to compensate the player for his winnings.Pricing of contracts may account for additional factors such as, forexample:

-   -   Times or dates on which the contract is to be executed.    -   The gaming device on which the contract is to be executed    -   Flexibility in the contract's execution.    -   A player's playing history.    -   The importance of the player as a customer of the casino.

For example, a contract that is to be executed during a period of lowcustomer activity at a casino may be priced at a discount. This isbecause a casino would like to encourage the use of gaming devices thatare otherwise empty. Alternatively, a casino may want to discourage thepurchase of contracts during times of high customer traffic, and socontracts may be higher priced at such times.

If a contract has flexibility as to when it may be executed, then thisallows the casino to execute contracts only during times when gamingdevices would not otherwise be in use. Therefore, such a contract mightbe priced more favorably.

A contract that is executed at an unpopular gaming device, for example,might be priced more favorably for the player so as to encourage the useof that device.

If a player shows signs of nearing the end of his gambling session, acontract might be priced at a discount for that player. For example, aplayer might be slowing his rate of play, indicating boredom. A playermight be lowering his wager size, indicating a decreasing bankroll. Aplayer might simply have been at a gaming device for such a long timethat he would almost necessarily be hungry enough to leave at anymoment. Providing a discount on a contract to such players wouldencourage them to remain gambling for at least the time it takes toexecute the contract.

13. Settlement

In some embodiments, the casino acts as the intermediary in transactionsbetween a player and the insurer. The casino is an intermediary, forexample, when its gaming devices collect a player's payment for acontract, even though that payment is meant to go to the insurer. Thecasino is also an intermediary when it does not collect losses from aplayer, but from an insurer.

Since the casino may engage in many transactions with the insurer, itwould potentially be inefficient for the casino to transfer money to theinsurer, or vice versa, after every transaction. Therefore, the casinoor the insurer may maintain records of how much one owes the other. Thecasino and the insurer may then settle their accounts periodically. Ifthe casino owes the insurer money, then the casino may wire money to theinsurer. If the insurer owes the casino, then the insurer may wiremoney. Of course, many other methods of settlement are possible.

In cases where a contract has resulted in a net win for the player, theplayer must be paid. If the player is at the casino, he may enter into agaming device a password or other identifier of himself or of hiscontract. The gaming device may then access a database in the casinoserver containing the details of the contract, including the amount owedto the player. The gaming device may then payout the amount owed in theform of cash, tokens, paper receipts or vouchers, digital cash, digitalreceipts, etc. The player may also collect his winnings at a casinodesk, perhaps after presenting identification.

If a player is remote from a casino when his contract has finishedexecuting, then the player may be sent his winnings either by theinsurer or the casino. If the insurer provides the winnings, then thecasino may later reimburse the insurer in the amount of the winnings.The winnings may be sent in the form of cash, check, money order, etc.The winnings may be sent by postal mail, by wire transfer, by directdeposit, by email as digital cash, etc.

In some embodiments, the casino may simply keep the player's winnings ina player account at a casino, to be accessed by the player next time hevisits the casino. The winnings may, in the mean time, accumulateinterest. The casino (or insurer) may also alert the player that hiscontract has finished executing and that he has winnings. The player maybe instructed to come to the casino and pick them up.

In some embodiments, the player may have left instructions to take anywinnings from a first contract and purchase a second contract. Thisallows for the notion of a meta-contract. Just as a contract may specifyhow to allocate money for pulls, a meta-contract would describe how toallocate money for contracts. There could then be meta-meta-contracts,and so on.

Numerous variations on the above-described contract embodiments of thepresent invention may be practiced without departing from the spirit andscope of the present invention. For example, a player may be halfwaythrough a contract and have negative two hundred (−200) accumulatedcredits. The player might therefore lose all hope of winning enough toovercome the two hundred-credit (200-credit) deficit, and thus loseinterest in the contract. Therefore, in one embodiment, a player who iswell below a threshold number of accumulated credits for winning mayplay for an altered pay table. Low paying outcomes may be eliminated,while the likelihood of achieving high paying outcomes may increase.This is because a player with a two hundred-credit (200-credit) deficitprobably doesn't care about a win of ten (10) credits, but does careabout a win of five hundred (500) credits. The overall hold percentageof the machine may remain constant. In some embodiments, the alterationof the pay tables is an automatic function of the number of pullsremaining and the credit deficit of the player. In other embodiments,the player must request an alteration of the pay tables. As an example,a player may select an option that says, “Let me play just for thejackpot. Eliminate everything else and make the jackpot more likely.”The player may or may not have to pay for an alteration of the paytables. In a more general sense, the pay tables may change such that thestandard deviation of the payout for a particular handle pull changeseven as hold percentage may remain constant.

In another embodiment, a player might purchase a contract at a casinodesk and receive a token that indicates the type of contract. The playermight then deposit the token into a gaming device. The gaming devicewould then recognize the token and be able to execute the contract.

A player may have the privilege of entering into favorable contractsafter a fixed amount of initial betting. For example, if the playerwagers for an hour, he may be able to enter into a contract where eachpull is at true odds. That is each pull pays back, on average, the sameamount that was put in. Typically the pull pays back less. In yetanother embodiment, a player may receive better odds on contract playwhen he is recommended to the casino by a friend.

In some embodiments, certain results of a pull may terminate a contractearly. For example, if a player hits the jackpot, the contract mayterminate. In other embodiments a player's accumulated credits can bedisplayed to a player as a function of time in the form of a graph. Thegraph may look much like graphs used to plot the price of a stock marketindex as a function of time. In some embodiments, a player wins money orsome other prize if the graph takes on a certain shape. For example, ifthe line of the graph is such that it slips between several sets ofmarkers (much like a skier on a slalom course), then the player may wina large prize.

In some embodiments, a player's winnings on each pull of the contractare reinvested into the contract, whereas in other embodiments they arenot. In one example, a player purchases a contract for one hundreddollars ($100). The player instructs the gaming device to gamble the onehundred dollars ($100) until it is all gone. However, any winnings arenot to be used to gamble, they are to be sent directly to the player. Ina second example, the player purchases a contract for one hundreddollars ($100) and instructs the gaming device to gamble the one hundreddollars ($100) until it is gone or until it has become two hundreddollars ($200). Here, the player elects to reinvest winnings, using thewinnings to pay for new handle pulls even after one hundred dollars($100) worth of handle pulls has been made already.

A contract may reward a player based on any second order data, ormeta-data about one or more outcomes. Examples include rewarding theplayer if three like outcomes occur in a row, if twenty (20) cherriescome up in ten (10) sequential spins, if the players accumulated creditsever reach one hundred (100), etc. An example previously mentioned isrewarding a player based on the pattern of a graph of accumulatedwinnings as a function of time. A player might choose the“meta-outcomes” on which he desires to be rewarded, and the gamingdevice may figure the corresponding odds and the size of the rewardshould the meta-outcome occur.

A player may be rewarded with the downside of a sequence of outcomesmuch as buying insurance gives him the upside. For example, a playerpays a fixed sum of money, and collects winnings for every dollar in thenegative the contract finishes at. Thus, if a contract ends with theplayer having negative twenty (−20) accumulated credits, then the playercollects twenty (20) credits.

A contract may apply to a “best 100” sequence of a larger sequence ofpulls. For example, the player pays one hundred dollars ($100) for acontract of one thousand (1000) pulls. From those one thousand (1000)pulls, the player gets to choose any one hundred (100) consecutiveoutcomes to determine his winnings, and can disregard the rest of theoutcomes. Thus the player can say he wants to use outcomes number fivehundred and six (506) through six hundred and five (605). Perhaps, forexample, there was a “hot streak” during that sequence. The player'swinnings are then determined solely based on what happened between pullsfive hundred and six (506) through six hundred and five (605). Thismight result in winnings of two hundred dollars ($200), whereas havingcounted all one thousand (1000) pulls would have resulted in a net lossfor the player. Of course, the gaming device may automatically choosethe most favorable sequence for the player.

A player may choose his favorite outcome and receive higher payouts forthat outcome, special privileges for receiving that outcome (e.g., theability to terminate a contract), etc.

C. Contract System Architecture

Returning now to the figures, in FIG. 17, a schematic view of a system1700 according to some embodiments is shown. The system 1700 may, forexample, comprise a representation of an embodiment of a flat rate playcontract system configured to carry out the contract embodimentsdescribed herein. The system 1700 generally comprises a casino server1705 in communication with insurer device 1710, a gaming device 1715,and/or a player device 1720. As used herein, a device (including thecasino server 1705, the insurer device 1710, the gaming device 1715,and/or the player device 1720) may communicate, for example, through acommunication network such as a Local Area Network (LAN), a Wide AreaNetwork (WAN), a Metropolitan Area Network (MAN), a Public SwitchedTelephone Network (PSTN), a proprietary network, a Wireless AccessProtocol (WAP) network, or an Internet Protocol (IP) network such as theInternet, an intranet or an extranet. Moreover, as used herein, acommunication network includes those enabled by wired or wirelesstechnology.

It should be understood that any number of gaming devices and any numberof player devices may be used in system 1700. Although the system 1700includes both a casino server 1705 and an insurer device 1710 asillustrated, one or the other of these elements may be omitted (forexample, the insurer device 1710 may be omitted in embodiments that donot include an insurer and/or where the casino acts as the insurer).Similarly, although the system 1700 includes both a gaming device 1715and a player device 1720 as illustrated, one or more of theseembodiments may be omitted (for example, the player device 1720 may beomitted if the casino has not implemented remote gaming). Further, someor all of the functionality of a casino server 1705 may be carried outby insurer device 1710 and vice versa. Similarly, some or all of thefunctionality of casino server 1705 and/or insurer device 1710 may becarried out by gaming device 1715 and vice versa. In one embodiment, thecasino server 1705 comprises one or more computers that are connected toa remote database server.

D. Contract Embodiment Device Architectures

Turning now to FIG. 18, a schematic view of a casino server 1705according to some embodiments is shown. The casino server 1705 may be,for example, an illustration of an embodiment of the casino server 1705from FIG. 17. The casino server 1705 generally comprises a processor1805 in communication with a communications port 1810 and storage device1815. Contained in the storage device 1815 is a program 1820, a playerdatabase 1825, a gaming device database 1830, and/or a contractsdatabase 1835. The processor 1805 performs instructions of the program1820, and thereby operates in accordance with the embodiments describedherein. The program 1820 may be stored in a compressed, uncompiled,and/or encrypted format. The program 1820 furthermore may includeprogram elements that may be necessary, such as an operating system, adatabase management system, and “device drivers” used by the processor1805 to interface with peripheral devices (not shown). Appropriateprogram elements are known to those skilled in the art.

Note that the processor 1805 and the storage device 1815 may be, forexample, located entirely within a single computer or other computingdevice or located in separate devices coupled through a communicationchannel.

Turning now to FIG. 19, a schematic view of an insurer device 1710according to some embodiments is shown. The insurer device 1710 may be,for example, an illustration of an embodiment of the insurer device 1710from FIG. 17. The insurer device 1710 may generally comprise a processor1905 in communication with a communications port 1910 and a storagedevice 1915. The storage device 1915 stores a program 1920. Theprocessor 1905 performs instructions of the program 1920, and therebyoperates in accordance with embodiments describe herein. The program1920 may be stored in a compressed, un-compiled, and/or encryptedformat. The program 1920 furthermore may include program elements thatmay be necessary, such as an operating system, a database managementsystem, and “device drivers” used by the processor 1905 to interfacewith peripheral devices (not shown). Appropriate program elements areknown to those skilled in the art. Note that the processor 1905 and thestorage device 1915 may be, for example, located entirely within asingle computer or other computing device or located in separate devicescoupled through a communication channel.

Turning now to FIG. 20, a schematic view of a gaming device 1715according to some embodiments is shown. The gaming device 1715 may, forexample, be an illustration of an embodiment of the gaming device 1715from FIG. 17. The gaming device 1715 may generally comprise a processor2005 in communication with a communications port 2010, an input device2015, an output device 2020, and a storage device 2025. The storagedevice 2025 stores a program 2030. The processor 2005 performsinstructions of the program 2030, and thereby operates in accordancewith embodiments described herein. The program 2030 may be stored in acompressed, un-compiled, and/or encrypted format. The program 2030furthermore includes program elements that may be necessary, such as anoperating system, a database management system, and “device drivers”used by the processor 2005 to interface with peripheral devices.Appropriate program elements are known to those skilled in the art.

Note that the processor 2005 and the storage device 2025 may be, forexample, located entirely within a single computer or other computingdevice or located in separate devices coupled through a communicationchannel.

The input device 2015 may comprise, for example, a player slot cardinterface, a keypad, a touch-screen, a microphone, and/or any otherdevice which allows a player to input information into gaming device1715. The output device 2020 may comprise, for example, a display area,a microphone, and/or any other device that allows the gaming device 1715to output information to a player. The gaming device 1715 may comprise,for example, a slot machine (such as the slot machines 102, 202described herein), video poker machine, video keno machine, and/or avideo blackjack machine. A combination of these types of machines may beused in embodiments where the casino server 1705 of FIG. 17 and/or FIG.18 is in communication with more than one gaming device 1715.

Turning now to FIG. 21, a schematic view of a player device 1720according to some embodiments is shown. The player device 1720 may be,for example, an illustration of an embodiment of the player device 1720from FIG. 17. The player device 1720 may be, for example, a PersonalComputer (PC), laptop, Personal Digital Assistant (PDA), a cellulartelephone, a pager, and/or any other device that allows a player toremotely monitor and participate in play of a gaming device inaccordance with some embodiments. The player device 1720 may generallycomprise a processor 2105 in communication with a communications port2110 and a storage device 2115. The storage device 2115 stores a program2120. The processor 2105 performs instructions of the program 2120, andthereby operates in accordance with embodiments described herein. Theprogram 2120 may be stored in a compressed, un-compiled, and/orencrypted format. The program 2120 furthermore may include programelements that may be necessary, such as an operating system, a databasemanagement system, and “device drivers” used by the processor 2105 tointerface with peripheral devices. Appropriate program elements areknown to those skilled in the art. Note that the processor 2105 and thestorage device 2115 may be, for example, located entirely within asingle computer or other computing device or located in separate devicescoupled through a communication channel.

It should be noted that any and any or all of the processors 1805, 1905,2005, 2105 described in conjunction with any of FIG. 18, FIG. 19, FIG.20, and/or FIG. 21 may comprise one or more microprocessors such as oneor more INTEL® Pentium® processors. Further, any and all of the storagedevices 1815, 1915, 2025, 2115 described in conjunction with any of FIG.18, FIG. 19, FIG. 20, and/or FIG. 21 may comprise any appropriatestorage device, including combinations of magnetic storage devices(e.g., magnetic tape and hard disk drives), optical storage devices andsemiconductor memory devices, such as RAM devices and/or ROM devices.

E. Contract Embodiment Data Structures

Examples of databases that may be used in connection with the system1700 of FIG. 17 will now be described in detail with respect to FIG. 22,FIG. 23, and FIG. 24. Each figure depicts a database in which the datais organized according to a data structure in accordance with someembodiments. The data may be stored, for example, on a computer readablemedium and be accessible by a program executed on a data processingsystem. The schematic illustrations and accompanying descriptions of thedatabases presented herein are exemplary, and any number of otherdatabase arrangements could be employed besides those suggested by thefigures.

1. Player Database

Referring to FIG. 22, a table illustrating an embodiment of a playerdatabase 1825 according to some embodiments is shown. In someembodiments, the player database 1825 may be stored at the casino server1705 shown in FIG. 17 and/or may be an illustration of one embodiment ofthe player database 1825 of FIG. 18. The player database 1825 maygenerally include entries identifying players that may be participatingin contracts for flat rate play sessions (e.g., associated with thesystem 1700 of FIG. 17). The player database 1825 may also define fields2205, 2210, 2215, 2220, 2225, 2230, 2235 for each of the entries. Thefields may comprise, for example, (i) a player identifier field 2205(e.g., that uniquely identifies a player, (ii) a name field 2210associated with the player, (iii) an address field 2215 that facilitatescommunications with the player, (iv) a financial account identifierfield 2220, that may store information such as a credit and/or debitcard account number, associated with the player through which paymentmay be obtained and to which player winnings may be credited, (v) ademographic information filed 2225 that may be utilized to determine aprice or other terms for a contract, (vi) a credits field 2230 that mayrepresent the amount of casino credits associated with the player,and/or (vii) a lifetime coin in field 2235 that represents the amount ofcoin in wagered by the player over the course of their relationship withthe casino and/or insurer.

2. Gaming Device Database

Referring to FIG. 23, a table illustrating an embodiment of a gamingdevice database 1830 according to some embodiments is shown. The gamingdevice database 1830 may be stored, for example, at the casino server1705 shown in FIG. 17 and/or may be an illustration of one embodiment ofthe gaming device database 1830 of FIG. 18. The gaming device database1830 may generally include entries identifying gaming devices operatedby the casino. The gaming device database 1830 may also define fields2305, 2310, 2315 for each of the entries. The fields may comprise, forexample (i) a gaming device identifier field 2305 that includesinformation that identifies a gaming device, (ii) a name field 2310storing information associated with the gaming devices, such as, forexample, “Diamond Mine®”, and/or (iii) a manufacturer field 2315 storingthe name of the manufacturer of the gaming device.

3. Contract Database

Referring to FIG. 24, a table illustrating an embodiment of a contractdatabase 1835 that may be stored at the casino server 1705 shown in FIG.17 and/or may illustrate an embodiment of the contract database 1835 ofFIG. 18. The contract database 1835 may generally include entriesidentifying contracts that may or have been purchased via the system1700 of FIG. 17. The contract database 1835 may also define fields 2405,2410, 2415, 2420, 2425, 2430, 2435, 2440 for each of the entries. Thefields may comprise, for example (i) a contract identifier field 2405that identifies a contract that has been purchased or is available forpurchase by a player, (ii) a player identifier field 2410 thatidentifies a player, if any, that may be associated with the contract,(iii) an initial bankroll field 2415, (iv) a description field 2420 thatdescribes the terms of the contract, (v) a cost field 2425 of thecontract, (vi) a result field 2430 that indicates the current status ofthe contract, (vii) an amount owed the player field 2435, and/or (viii)an amount owed the insurer field 2440.

A method that may be used in connection with the system 1700 of FIG. 17according to some embodiments will now be described in detail withrespect to FIG. 25. In FIG. 25, a flowchart of a method 2500 accordingto some embodiments is shown. The method 2500 may be performed, forexample, by the casino server 1705 of FIG. 17 in response to a player'srequest to purchase a contract and after determining the price and termsof the contract the player wishes to purchase. The flowcharts depictedherein do not imply a fixed order to the steps, and embodiments may bepracticed in any order that is or becomes practicable.

In some embodiments, the method 2500 begins upon receipt of payment froma player for a fixed number of pulls, in step 2505. In other embodimentsthis step may comprise receipt of payment for a fixed duration of timeduring which the player may play. Receipt of payment may comprise, forexample, receipt of a monetary input into a gaming device (such as thegaming device 1715 of FIG. 17 and/or FIG. 20) or receipt of (and, e.g.,approval of a charge on) a financial account identifier. The receivedpayment, or an indication of it, is then transmitted to an insurer instep 2510. Outcomes are then generated for a fixed number of pulls instep 2515. An adjustment of a tally of the player's accumulated creditsbased on the outcomes is performed in step 2520.

In step 2525 it is determined whether the adjusted tally exceeds apredetermined threshold. If it does, the method 2500 proceeds to step2535 where the player is paid the amount by which the tally exceeds thethreshold. Payment to the player may be achieved by, for example,outputting a monetary amount comprising the payment to the player at thegaming device or by crediting the amount of the payment to a financialaccount identifier associated with the player. If it is determined instep 2525 that the adjusted tally does not exceed the predeterminedthreshold then the method 2500 proceeds to step 2530 in which the amountby which the tally falls short of the threshold is collected from theinsurer.

Although the foregoing preferred embodiments employ slot machines andvideo poker machines, it is within the scope of the present invention toemploy other types of gaming devices, such as video poker machines,video roulette machines, video blackjack machines and the like. Forexample, in an embodiment using a video poker machine, the playerselected price parameters include identifying only specific card hands,such as a royal flush, as active in the jackpot structure.

VII. Rules of Interpretation

Numerous embodiments are described in this patent application, and arepresented for illustrative purposes only. The described embodiments arenot, and are not intended to be, limiting in any sense. The presentlydisclosed invention(s) are widely applicable to numerous embodiments, asis readily apparent from the disclosure. One of ordinary skill in theart will recognize that the disclosed invention(s) may be practiced withvarious modifications and alterations, such as structural, logical,software, and electrical modifications. Although particular features ofthe disclosed invention(s) may be described with reference to one ormore particular embodiments and/or drawings, it should be understoodthat such features are not limited to usage in the one or moreparticular embodiments or drawings with reference to which they aredescribed, unless expressly specified otherwise.

The present disclosure is neither a literal description of allembodiments of the invention nor a listing of features of the inventionthat must be present in all embodiments.

Neither the Title (set forth at the beginning of the first page of thispatent application) nor the Abstract (set forth at the end of thispatent application) is to be taken as limiting in any way as the scopeof the disclosed invention(s). The term “product” means any machine,manufacture and/or composition of matter as contemplated by 35 U.S.C.§101, unless expressly specified otherwise.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “one or more embodiments”, “someembodiments”, “one embodiment” and the like mean “one or more (but notall) disclosed embodiments”, unless expressly specified otherwise.

A reference to “another embodiment” in describing an embodiment does notimply that the referenced embodiment is mutually exclusive with anotherembodiment (e.g., an embodiment described before the referencedembodiment), unless expressly specified otherwise.

The terms “including”, “comprising” and variations thereof mean“including but not limited to”, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expresslyspecified otherwise.

The term “plurality” means “two or more”, unless expressly specifiedotherwise.

The term “herein” means “in the present application, including anythingwhich may be incorporated by reference”, unless expressly specifiedotherwise.

The phrase “at least one of”, when such phrase modifies a plurality ofthings (such as an enumerated list of things) means any combination ofone or more of those things, unless expressly specified otherwise. Forexample, the phrase at least one of a widget, a car and a wheel meanseither (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car,(v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, acar and a wheel.

The phrase “based on” does not mean “based only on”, unless expresslyspecified otherwise. In other words, the phrase “based on” describesboth “based only on” and “based at least on”.

The term “whereby” is used herein only to precede a clause or other setof words that express only the intended result, objective or consequenceof something that is previously and explicitly recited. Thus, when theterm “whereby” is used in a claim, the clause or other words that theterm “whereby” modifies do not establish specific further limitations ofthe claim or otherwise restricts the meaning or scope of the claim.

Where a limitation of a first claim would cover one of a feature as wellas more than one of a feature (e.g., a limitation such as “at least onewidget” covers one widget as well as more than one widget), and where ina second claim that depends on the first claim, the second claim uses adefinite article “the” to refer to the limitation (e.g., “the widget”),this does not imply that the first claim covers only one of the feature,and this does not imply that the second claim covers only one of thefeature (e.g., “the widget” can cover both one widget and more than onewidget).

Each process (whether called a method, algorithm or otherwise)inherently includes one or more steps, and therefore all references to a“step” or “steps” of a process have an inherent antecedent basis in themere recitation of the term ‘process’ or a like term. Accordingly, anyreference in a claim to a ‘step’ or ‘steps’ of a process has sufficientantecedent basis.

When an ordinal number (such as “first”, “second”, “third” and so on) isused as an adjective before a term, that ordinal number is used (unlessexpressly specified otherwise) merely to indicate a particular feature,such as to distinguish that particular feature from another feature thatis described by the same term or by a similar term. For example, a“first widget” may be so named merely to distinguish it from, e.g., a“second widget”. Thus, the mere usage of the ordinal numbers “first” and“second” before the term “widget” does not indicate any otherrelationship between the two widgets, and likewise does not indicate anyother characteristics of either or both widgets. For example, the mereusage of the ordinal numbers “first” and “second” before the term“widget” (1) does not indicate that either widget comes before or afterany other in order or location; (2) does not indicate that either widgetoccurs or acts before or after any other in time; and (3) does notindicate that either widget ranks above or below any other, as inimportance or quality. In addition, the mere usage of ordinal numbersdoes not define a numerical limit to the features identified with theordinal numbers. For example, the mere usage of the ordinal numbers“first” and “second” before the term “widget” does not indicate thatthere must be no more than two widgets.

When a single device or article is described herein, more than onedevice or article (whether or not they cooperate) may alternatively beused in place of the single device or article that is described.Accordingly, the functionality that is described as being possessed by adevice may alternatively be possessed by more than one device or article(whether or not they cooperate).

Similarly, where more than one device or article is described herein(whether or not they cooperate), a single device or article mayalternatively be used in place of the more than one device or articlethat is described. For example, a plurality of computer-based devicesmay be substituted with a single computer-based device. Accordingly, thevarious functionality that is described as being possessed by more thanone device or article may alternatively be possessed by a single deviceor article.

The functionality and/or the features of a single device that isdescribed may be alternatively embodied by one or more other devicesthat are described but are not explicitly described as having suchfunctionality and/or features. Thus, other embodiments need not includethe described device itself, but rather can include the one or moreother devices which would, in those other embodiments, have suchfunctionality and/or features.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. On the contrary, such devices need only transmit to eachother as necessary or desirable, and may actually refrain fromexchanging data most of the time. For example, a machine incommunication with another machine via the Internet may not transmitdata to the other machine for weeks at a time. In addition, devices thatare in communication with each other may communicate directly orindirectly through one or more intermediaries.

A description of an embodiment with several components or features doesnot imply that all or even any of such components and/or features arerequired. On the contrary, a variety of optional components aredescribed to illustrate the wide variety of possible embodiments of thepresent invention(s). Unless otherwise specified explicitly, nocomponent and/or feature is essential or required.

Further, although process steps, algorithms or the like may be describedin a sequential order, such processes may be configured to work indifferent orders. In other words, any sequence or order of steps thatmay be explicitly described does not necessarily indicate a requirementthat the steps be performed in that order. The steps of processesdescribed herein may be performed in any order practical. Further, somesteps may be performed simultaneously despite being described or impliedas occurring non-simultaneously (e.g., because one step is describedafter the other step). Moreover, the illustration of a process by itsdepiction in a drawing does not imply that the illustrated process isexclusive of other variations and modifications thereto, does not implythat the illustrated process or any of its steps are necessary to theinvention, and does not imply that the illustrated process is preferred.

Although a process may be described as including a plurality of steps,that does not indicate that all or even any of the steps are essentialor required. Various other embodiments within the scope of the describedinvention(s) include other processes that omit some or all of thedescribed steps. Unless otherwise specified explicitly, no step isessential or required.

Although a product may be described as including a plurality ofcomponents, aspects, qualities, characteristics and/or features, thatdoes not indicate that all of the plurality are essential or required.Various other embodiments within the scope of the described invention(s)include other products that omit some or all of the described plurality.

An enumerated list of items (which may or may not be numbered) does notimply that any or all of the items are mutually exclusive, unlessexpressly specified otherwise. Likewise, an enumerated list of items(which may or may not be numbered) does not imply that any or all of theitems are comprehensive of any category, unless expressly specifiedotherwise. For example, the enumerated list “a computer, a laptop, aPDA” does not imply that any or all of the three items of that list aremutually exclusive and does not imply that any or all of the three itemsof that list are comprehensive of any category.

Headings of sections provided in this patent application and the titleof this patent application are for convenience only, and are not to betaken as limiting the disclosure in any way.

“ Determining” something can be performed in a variety of manners andtherefore the term “determining” (and like terms) includes calculating,computing, deriving, looking up (e.g., in a table, database or datastructure), ascertaining and the like.

It will be readily apparent that the various methods and algorithmsdescribed herein may be implemented by, e.g., appropriately programmedgeneral purpose computers and computing devices. Typically a processor(e.g., one or more microprocessors) will receive instructions from amemory or like device, and execute those instructions, therebyperforming one or more processes defined by those instructions. Further,programs that implement such methods and algorithms may be stored andtransmitted using a variety of media (e.g., computer readable media) ina number of manners. In some embodiments, hard-wired circuitry or customhardware may be used in place of, or in combination with, softwareinstructions for implementation of the processes of various embodiments.Thus, embodiments are not limited to any specific combination ofhardware and software

A “processor” means any one or more microprocessors, CPU devices,computing devices, microcontrollers, digital signal processors, or likedevices.

The term “computer-readable medium” refers to any medium thatparticipates in providing data (e.g., instructions) that may be read bya computer, a processor or a like device. Such a medium may take manyforms, including but not limited to, non-volatile media, volatile media,and transmission media. Non-volatile media include, for example, opticalor magnetic disks and other persistent memory. Volatile media includeDRAM, which typically constitutes the main memory. Transmission mediainclude coaxial cables, copper wire and fiber optics, including thewires that comprise a system bus coupled to the processor. Transmissionmedia may include or convey acoustic waves, light waves andelectromagnetic emissions, such as those generated during RF and IR datacommunications. Common forms of computer-readable media include, forexample, a floppy disk, a flexible disk, hard disk, magnetic tape, anyother magnetic medium, a CD-ROM, DVD, any other optical medium, punchcards, paper tape, any other physical medium with patterns of holes, aRAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip orcartridge, a carrier wave as described hereinafter, or any other mediumfrom which a computer can read.

Various forms of computer readable media may be involved in carryingsequences of instructions to a processor. For example, sequences ofinstruction (i) may be delivered from RAM to a processor, (ii) may becarried over a wireless transmission medium, and/or (iii) may beformatted according to numerous formats, standards or protocols, such asBluetooth™, TDMA, CDMA, 3G.

Where databases are described, it will be understood by one of ordinaryskill in the art that (i) alternative database structures to thosedescribed may be readily employed, and (ii) other memory structuresbesides databases may be readily employed. Any illustrations ordescriptions of any sample databases presented herein are illustrativearrangements for stored representations of information. Any number ofother arrangements may be employed besides those suggested by, e.g.,tables illustrated in drawings or elsewhere. Similarly, any illustratedentries of the databases represent exemplary information only; one ofordinary skill in the art will understand that the number and content ofthe entries can be different from those described herein. Further,despite any depiction of the databases as tables, other formats(including relational databases, object-based models and/or distributeddatabases) could be used to store and manipulate the data typesdescribed herein. Likewise, object methods or behaviors of a databasecan be used to implement various processes, such as the describedherein. In addition, the databases may, in a known manner, be storedlocally or remotely from a device that accesses data in such a database.

The present invention can be configured to work in a network environmentincluding a computer that is in communication, via a communicationsnetwork, with one or more devices. The computer may communicate with thedevices directly or indirectly, via a wired or wireless medium such asthe Internet, LAN, WAN or Ethernet, Token Ring, or via any appropriatecommunications means or combination of communications means. Each of thedevices may comprise computers, such as those based on the Intel®Pentium® or Centrino™ processor, that are adapted to communicate withthe computer. Any number and type of machines may be in communicationwith the computer.

The present disclosure provides, to one of ordinary skill in the art, anenabling description of several embodiments and/or inventions. Some ofthese embodiments and/or inventions may not be claimed in the presentapplication, but may nevertheless be claimed in one or more continuingapplications that claim the benefit of priority of the presentapplication. Applicants intend to file additional applications to pursuepatents for subject matter that has been disclosed and enabled but notclaimed in the present application.

1. A method, comprising: receiving an indication of a price a player iswilling to pay for flat rate play at a gaming device; determining adesired profit of the flat rate play at the gaming device; calculating,based at least upon the price and the desired profit, a target cost forthe flat rate play at the gaming device; determining a flat rate playsession with an expected cost substantially equal to the target cost,wherein the flat rate play session is defined by one or more parameters;and initializing play of the flat rate play session in accordance withthe one or more parameters.
 2. The method of claim 1, furthercomprising: offering the flat rate play session to the player; anddetermining an acceptance of the offer by the player.
 3. The method ofclaim 2, wherein the determining of the acceptance comprises: receivingan indication of an acceptance of the offer by the player.
 4. The methodof claim 1, wherein the desired profit comprises at least one of adesired profit margin and a desired profit rate.
 5. The method of claim1, wherein the determining of the flat rate play session comprises:determining a plurality of flat rate play sessions; determining anexpected cost for each of the plurality of flat rate play sessions; andselecting the flat rate play session with the expected cost mostsubstantially equal to the target cost.
 6. The method of claim 1,further comprising: displaying the one or more parameters that definethe flat rate play session.
 7. The method of claim 1, furthercomprising: receiving payment in the amount of the price the player iswilling to pay.
 8. The method of claim 1, further comprising:determining the expected cost of the flat rate play session.
 9. Themethod of claim 1, wherein the expected cost of the flat rate playsession is determined based on at least one of (i) a simulation, (ii) amathematical simulation, (iii) a mathematical model, and (iv) a historyof flat rate play session costs.
 10. The method of claim 1, wherein theone or more parameters comprises at least one of: (i) an amount wagered;(ii) a jackpot structure; (iii) a time of a day; (iv) a day of a week;(v) a day of a month; (vi) a day of a year; (vii) a week of a month;(viii) a week of a year; (ix) a month of a year; (x) a type of gamingdevice; (xi) a player status rating; (xii) an availability of a gamingdevice; (xiii) a forecasted availability of a gaming device; (xiv) anumber of active jackpots; (xv) a number of winning plays; (xvi) a timebetween plays; (xvii) a traffic of potential players; (xviii) stakes ofplay; and (xix) an external event.
 11. The method of claim 1, furthercomprising: determining the one or more parameters defining the flatrate play session.
 12. An apparatus, comprising: a processor; and amemory in communication with the processor, the memory storing a programthat when executed by the processor results in: receiving an indicationof a price a player is willing to pay for flat rate play at a gamingdevice; determining a desired profit of the flat rate play at the gamingdevice; calculating, based at least upon the price and the desiredprofit, a target cost for the flat rate play at the gaming device;determining a flat rate play session with an expected cost substantiallyequal to the target cost, wherein the flat rate play session is definedby one or more parameters; and initializing play of the flat rate playsession in accordance with the one or more parameters.
 13. The apparatusof claim 12, further comprising: an input device to receive theindication of the price from the player.
 14. A method, comprising:determining a price a player is willing to pay for flat rate play at agaming device; determining one or more parameters that define a flatrate play session with a retail price substantially equal to the pricethe player is willing to pay; and initializing play of the flat rateplay session in accordance with the one or more parameters.
 15. Themethod of claim 14, wherein the determining of the one or moreparameters comprises: determining a target cost for the flat rate playat the gaming device; and selecting values for the one or moreparameters that define the flat rate play session to have an expectedcost substantially equal to the target cost.
 16. The method of claim 14,wherein the flat rate play session comprises a plurality of flat rateplay sessions having retail prices substantially equal to the price theplayer is willing to pay, further comprising: selecting one of theplurality of flat rate play sessions.
 17. The method of claim 16,wherein the selected flat rate play session is a flat rate play sessionfrom the plurality of flat rate play sessions that has a retail pricemost substantially equal to the price the player is willing to pay. 18.The method of claim 14, wherein the flat rate play session comprises aplurality of flat rate play sessions having retail prices substantiallyequal to the price the player is willing to pay, further comprising:providing a menu of the plurality of flat rate play sessions to theplayer.
 19. The method of claim 18, further comprising: receiving anindication of a menu selection made by the player.
 20. The method ofclaim 14, wherein the price the player is willing to pay comprises abalance of credits associated with the player.